Copy Link
Add to Bookmark
Report

Info-Atari16 Digest Vol. 89 Issue 835

eZine's profile picture
Published in 
Info Atari16 Digest
 · 5 years ago

  

=========================================================================

INFO-ATARI16 Digest Wed, 20 Dec 89 Volume 89 : Issue 835

Today's Topics:
Dungeon Master and TOS 1.4
How to know we are in TOS 1.0?
I/O redirection to the printer
Optimism about Atari Canada
Problem with menu_text()
Ringing bells
----------------------------------------------------------------------

Date: 20 Dec 89 05:15:28 GMT
From: psuvm!sml108@psuvax1.cs.psu.edu
Subject: Dungeon Master and TOS 1.4
Message-ID: <89354.001528SML108@PSUVM.BITNET>

Has anyone successfully run Dungeon Master in TOS 1.4? I want to buy it but
I need to know this..... FAST... Send your replies via email...

Scott Le Grand aka SML108@PSUVM.PSU.EDU

------------------------------

Date: 19 Dec 89 19:14:31 GMT
From: fox!portal!atari!apratt@apple.com (Allan Pratt)
Subject: How to know we are in TOS 1.0?
Message-ID: <1903@atari.UUCP>

colas@modja.inria.fr (Colas Nahaboo) writes:

>My question is: what is the LEGAL way to know I am running on an ST with
>TOS 1.0 roms from a C program? [...]
>
>All I have seen is de-referencing the pointer
> unsigned char *ROMS_YEAR = 0x00fc0018L + 3L;
>which gives you the year of the TOS (on US and French tos it is 0x86), but
>this is undocumented, and will surely break on the STe, since the Roms are
>not in the same place!

Good for you! You're right, the ROMs are free to move from rev to rev.
So you can't use a constant for an address in the ROM. However, you
can use a variable, and there is one: the system variable _sysbase
at $4f2 holds the base of "the OS header" which is where things like
the date are kept.

This code extracts the date as a LONG from the OS header, no matter where
it lives:

char *sysbase = *(char **)0x4f2;
long romdate = *(long *)(sysbase + 0x18);

romdate will have a number like 0x04061989 for April 6, 1989.

>PPPS: and do not tell me to pay to become a registred developper, all my atari
>programming is public domain! :-)

That doesn't matter. If you paid to become a registered developer, you
would be able to look this stuff up instead of bothering all of us! :-)
You don't have to be a commercial developer to join the Atari developer
program. (I know I'm answering your question anyway -- think of it as
advertising. (If you're a Net God, *don't* think of it as advertising!))

============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt

------------------------------

Date: 19 Dec 89 09:45:06 GMT
From: mcsun!unido!ztivax!tumuc!guug!pcsbst!cochise!roland@uunet.uu.net
Subject: I/O redirection to the printer
Message-ID: <1174@pcsbst.UUCP>

Hallo Thomas,

UI0T@DKAUNI2.BITNET ("Thomas Koenig") writes:

>I am having a strange problem with I/O redirection. To redirect
>standard output to the printer, I wrote the following test program:

I think You just re-discovered one of the older bugs of TOS.
I have hit upon this problem when trying to redirect the messages
from Turbo-C ( commandline version ) to a file. For the compiler TCC
this worked fine, however, the linker put out only NULs. ( Substituting
ALN as linker solved this problem. )

A little disassembling showed that the linker used Cconout() for
basic output, whereas TCC relied on Fwrite( 1, ... ).

> Fclose (1);
> Fforce (1, printhandle);
> printf("Hello, world!\n");
>/* Cconws("Hello, world!\n"); */

So try:
Fwrite( 1, "Hello world!\n", 13 ) ; /* modulo correct ordering */

( This should work, and I suppose that the printf() is based on
F

------------------------------

Date: Wed, 20 Dec 1989 08:47 EST
From: Greg Csullog <01659%AECLCR.BITNET@Forsythe.Stanford.EDU>
Subject: Optimism about Atari Canada

One netter posted a note about what he perceives to be an upward turn in
Atari fortunes (e.g. 6 1040STEs sold by a dealer in Toronto). The following
is a copy of a note I sent to Geoff Earle, the national sales manager for
Atari Canada. Now, I really should not be posting this note for two reasons.
First, Mr. Earle has not had time to respond to it and second, I am sending
this note from my regular full time day job mainframe mailer and I should
not be doing any third party business on company time (I'll skip coffee
break this morning). However, if anything, this posting will have a negative
effect upon my Atari dealership because it points out the problems I have
had as a novice dealer. In addition, it is a general interest item that
is not business oriented so I hope my local management will forgive the minor
transgression (I am doing this for the greater good of Atari users,
not for personal gain).

I do want to point out that Atari Canada has tried its utmost to get me
through the problems in one piece (special thanks to Denise Carrol). However
I am a little disappointed to hear on the net that a Toronto dealer has
actually sold 1040STEs when I was told by Atari every day for the last two
weeks that there are no STEs available in Ontario (only a 'small shipment
to be sent west', whatever that means). As I say in the letter below, I want
to be honest with my customers, I expect the same of Atari Canada and its
relationship with its dealers.
=========================================================================
89.12.18

Attn: Mr. Geoffry Earle

To say the very least, my experiences with Atari Canada since
becoming a dealer have not been memorable.

1. The first problem started when Bruce Stetham made what seemed to
be a minor error and told me that 1040STE computers were
available in Toronto (in October). I advised my customers to
order STEs instead of the old 1040STs thinking that it would be
only a matter of days before Atari Canada could ship the
equipment.

Since October, I have been told a least 6 different dates for
STE availability. Two customers who had ordered STEs have since
acquired alternative (i.e. non Atari) systems. I have been
unable to sell 1040STs because everyone is waiting for the STEs.
As such, my bread-and-butter product, which was supposed to be
available, has put a large roadblock in sales.

I ordered two STs for store stock in lieu of STE product.

2. I have an order on the books for two STACYs with 20 meg hard
drives. I know that STACY availability was never specified and I
can accept the delays. Unlike the STE issue, I was not given a
lengthy list of delivery dates only to see each one missed.
Hopefully, Atari will have STACYs soon.

3. I ordered a PC4/12H and a PCC1424 EGA monitor. The PCC1424 was
not available and a PCM124 was substituted. When the PC and
monitor arrived, they were DOA. In addition, the shipping
cartons already had return authorization numbers and it is
likely that the system had previously been returned DOA to Atari
prior to shipment to me.

The PC had been ordered for a public display at one of the local
schools. I had to bite my lip and tell people that the PC
arrived DOA and apologized for advertising a system I could not
demonstrate.

The system was return on a CRA number and a credit issued.
However, the credit was for a mono system yet I had paid for a
colour system. Now, I am trying to get Atari's finance
department to correct the discrepancy between the surplus I
calculate to have on account with Atari and what Atari says I
have on account. Hopefully, this can be resolved soon.

In addition to the physical problems with the PC4, I advised
Bruce Corbett that the dealer book specs for this computer were
different from the machine that was delivered (different BIOS, 1
serial port not 2). I asked that I get clarification as to the
current specs for the computer. So far, I have not received any
information.

4. I ordered a Mega 2/SM124 system. The Mega 2 arrived DOA and was
returned. So, out of orders for four computers, two arrived DOA.
Let's hope the DOA frequency drops for future orders (I am still
waiting for the Mega 2 to return from Atari).

5. Today, I called Atari about the availability of the Atari
ABC286/30 computer (AT compatible) and I was told by both Denise
Carrol and a representative in your service department that they
had never even heard of this system. This response from Atari
was both unexpected and irritating. Having come close to
finalising the sale of an ABC286/30 with only the delivery date
to be determined, I was amazed that Atari staff claimed to have
never heard of a system that has a detailed spec sheet in the
dealer book.

Quite simply, this situation is unacceptable. How can I possibly
sell Atari equipment when I can put absolutely no faith in the
dealer book or the ability of Atari Canada to supply products?
The only problem I have selling Atari computers is Atari Canada.

I would like to find out from you, the National Sales manager, if I
can expect to receive a dealer book that has accurate information and
if I can be given realistic and reliable delivery dates for products.
Otherwise, I have to tell prospective customers that it is not a safe
bet to place an order for Atari computers. I am honest with my
customers, hopefully Atari Canada can be honest with its customers
the dealers.






Greg Csullog
Owner of Click Here Computers

------------------------------

Date: 19 Dec 89 16:21:11 GMT
From: bnrgate!bnr-fos!bigsur!bnr-rsc!oldfield@uunet.uu.net (John Oldfield)
Subject: Problem with menu_text()
Message-ID: <1616@bnr-rsc.UUCP>

This is from a friend who doesn't have net-access....
-------------------------------------------------------

Every time I try to update the text in a menu item,
my program crashes. The call I am using to change
the text is

menu_text(menu_ptr, ITEM_CONST, new_text);

menu_ptr - a pointer to the menu tree
ITEM_CONST - index of a menu item
- from the .H file created by a
resource construction program
new_text - pointer to a null-terminated
character string

I have tried using strings that are shorter, the same
length and longer than the existing menu item text.

I have tried putting wind_update(BEG_UPDATE) before
the menu_text call and wind_update(END_UPDATE) after.

I have tried putting menu_bar(menu_ptr, FALSE) before
the menu_text call and menu_bar(menu_ptr, TRUE) after.

I have also tried surrounding the menu_text call with
both wind_update and menu_bar calls.

What am I doing wrong? Please help.

-----------------------------------------------------

from John Oldfield oldfield@bnr-rsc

------------------------------

Date: Wed, 20 Dec 89 11:47:14 MEZ
From: ONM07%DMSWWU1A.BITNET@CUNYVM.CUNY.EDU (Julian Reschke)
Subject: Ringing bells
Message-ID: <8912201047.AA01413@freya.dmswwu-ether>

Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Tel.: 0251/861241
email: ONM07@DMSWWU1A.BITNET


------------------------------

End of INFO-ATARI16 Digest V89 Issue #835
*****************************************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT