colas@modja.inria.fr (Colas Nahaboo) (12/19/89)
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? The only legal way I knew of was Sversion,
but it returns 0,19 on both TOS 1.0 & TOS 1.2
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!
PS: I want to know this for formatting a disk: if it is TOS 1.0, use the
TWISTER assembly code, if not, use the Flopfmt primitive with -1 interleave.
PPS: this is for my PD copier, flip, which detects and kills viruses when
copying disks, which is I found the best time to catch them!!! I never get
infected anymore.
(moreover it searches for calls to Flopwrt in the boot sector, catching
virtually ANY new boot sector virus to come)
PPPS: and do not tell me to pay to become a registred developper, all my atari
programming is public domain! :-)
Colas NAHABOO BULL Research FRANCE -- Koala Project
(GWM X11 Window Manager)
Internet: colas@mirsa.inria.frwallace@oldtmr.dec.com (Ray Wallace) (12/19/89)
In article <452@mirsa.inria.fr>, 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? The only legal way I knew of was Sversion, >but it returns 0,19 on both TOS 1.0 & TOS 1.2 Attached is Alan Pratt's answer to the same question when it was posted about a year ago. # Subject: Re: Rom Identification # Posted: 24 Aug 88 18:22:24 GMT # Organization: Atari (US) Corporation, Sunnyvale, California # # In article <1402@kodak.UUCP> nelson@kodak.UUCP (bruce nelson) writes: # > Is there an official (or unofficial :-) way to identify which version # > of the Roms is installed in an ST? # > # > Bruce D. Nelson | UUCP: ...!rutgers!rochester!kodak!hawkeye!nelson # # The quick answer is this: the system variable _sysbase (at address # 0x4f2) contains a pointer to the base of the OS. The OS starts with a # header which identifies it. At offset 2 and 3 into this header are two # bytes: the major and minor revision numbers, respectively. Original RAM # TOS, as well as the first cut of ROMs, was, I believe, 1.0 (that is, # major byte is 1, minor is 0). The Mega ROMs are 1.2, and the new # release will be 1.4. You aren't missing revs: we're jumping them by two # for reasons I don't want to go into now. # # ============================================ # Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. # reflect those of Atari Corp. or anyone else. ...ames!atari!apratt --- Ray Wallace (INTERNET,UUCP) wallace@oldtmr.enet.dec.com (UUCP) ...!decwrl!oldtmr.enet!wallace (INTERNET) wallace%oldtmr.enet@decwrl.dec.com ---
klute@trillian (12/19/89)
Path: trillian !klute In article <452@mirsa.inria.fr> 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? The only legal way I knew of was Sversion, >but it returns 0,19 on both TOS 1.0 & TOS 1.2 Yesterday I sent a little program *with* *source* to Steven Grimm that finds out exactly that. It should be posted to comp.binaries.atari.st and comp.sources.atari.st really soon now. The program TOS_VERS shows TOS version number (with date and nickname (e. g. "Rainbow TOS")), GEMDOS version number and AES version number. The program is really short and should be self explanatory. If it is not, an article by Ken Badertscher is appended that explains how things are to be done. Not to mention that everything is of course perfectly legal. Dipl.-Inform. Rainer Klute klute@heike.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663
apratt@atari.UUCP (Allan Pratt) (12/20/89)
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
exspes@gdr.bath.ac.uk (P E Smee) (12/21/89)
In article <1903@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > >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!)) Your mileage may vary on this one, depending on which Atari subsidiary you have to deal with. I contacted Atari UK (some time ago, maybe I should try again) about the developers kit, and was told that in addition to the money I would have to inform them of my 'trading name', and would have to agree to keep them informed of what I was using the information to develop, so that they could ask me to stop if it interfered with their own internal or contracted-out development. The concept that I might just want it for fun didn't seem to be one which they could grasp. Since I was unable to comply with the first condition, and unwilling to comply with the second on principle, I dropped the idea. (Though I occasionally toy with the idea of having my mother buy me a US developers kit (she's in Pittsburgh PA) and forwarding it to me.) -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
apratt@atari.UUCP (Allan Pratt) (12/28/89)
exspes@gdr.bath.ac.uk (P E Smee) writes: >In article <1903@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >> ["Become a registered developer and your road will be paved with gold."] >Your mileage may vary on this one, depending on which Atari subsidiary >you have to deal with. I contacted Atari UK (some time ago, maybe I >should try again) about the developers kit, and was told that in >addition to the money I would have to inform them of my 'trading name', >and would have to agree to keep them informed of what I was using the >information to develop, so that they could ask me to stop if it >interfered with their own internal or contracted-out development. I find this appalling! Please, people, if you've had this experience, send me mail and I'll direct it to some people here. I never knew that becoming a developer meant Atari would try to stop you from doing something! (I can understand them letting you know what they're up to, to save you duplicating their effort, but not actually telling you to stop!) My appalled condition is personal, not corporate. For all I know, this might be Atari policy. It is *certainly* Atari policy to let the subsidiaries do whatever they want, but we can make suggestions. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt