========================================================================= 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 *****************************************