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