WOODALLP@VAX1.BHAM.AC.UK (06/08/89)
I have seen mention of TOS 1.0 and TOS 1.2, in Britain I have not seen any mention of these numbers, so far we have had TOS 0.19 (the first ROM TOS, this lasted until winter 87) and TOS 1.09 (which replaced it) as far as I know the mega TOS is just 1.09 with Blitter support. Thus the netter who used Sversion and got a reply of 0.19 just had the old TOS (with the British numbers or the program somehow interpreted the ROM to be the British version). Any comments please as I am no authority! A question, where are all the GDOS fonts, GDOS has been around a while now and apart from a British program called Calligrapher (hands up who is old enough to remember that one) it has been stable and useful, it is used by Timeworks, easydraw, Word-up and to a lesser extent by Cyber Studio, Uniterm and Degas Elite. So where are all the fonts, all too long we have been stuck using Swiss, Dutch and a 12pt typewriter font and a promise of more to come, but where are they. Please, please Atari (or anyone) please throw a few more GDOS fonts into the PD (or even sell them!) as I for one would be grateful Has anyone managed to get the hyperscreen working yet, I would be pleased to hear from anyone who has, a friend of mine is to try next week and I will report back if it works. Ta Ta For Now: Phil Woodall Elec Eng Dept University of Birmingham England B15 2TT Janet: janet%uk.ac.bham.vax1::woodallp woodallp%vax1.bham.ac.uk@cunyvm.cuny.edu woodallp%vax1.bham.ac.uk@nss.cs.ucl.ac.uk p.s. I will report back if it doesnt work as well.
apratt@atari.UUCP (Allan Pratt) (06/13/89)
In article <8906090105.AA10969@ucbvax.Berkeley.EDU> WOODALLP@VAX1.BHAM.AC.UK writes: > I have seen mention of TOS 1.0 and TOS 1.2, in Britain I have not seen > any mention of these numbers [...] Sversion() only gives the version number for GEMDOS, and that didn't change between original ROMs and Mega ROMs. The TOS version number is available as the second word of the OS header, whose address can be found at _sysbase, $4f2. Original RAM TOS and also original ROM TOS were both 1.0 (regrettably), but since RAM TOS is no longer supported this isn't a big deal. Mega TOS was 1.2 (with more changes than you think), and the new TOS (available now to USA developers -- write J. Patton at Atari for info) is 1.4. By "x.y" I mean the first byte of that word is x and the second one is y. NEVER NEVER NEVER use an absolute address like $FC0000 because if we ever move the ROM start address (HINT HINT) your program won't work! The only absolute addresses in any TOS program should refer to published system variables or hardware things like interrupt vectors. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
neil@cs.hw.ac.uk (Neil Forsyth) (06/14/89)
In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >NEVER NEVER NEVER use an absolute address like $FC0000 because if we >ever move the ROM start address (HINT HINT) your program won't work! The >only absolute addresses in any TOS program should refer to published >system variables or hardware things like interrupt vectors. WAIT! Your not thinking of moving the I/O addresses are you? If you do that would be disasterous! "HINT HINT" - GDOS in the ROM? Address space >192K? Upgrades for existing ST's? >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt _____________________________________________________________________________ / DISCLAIMER: Unless otherwise stated, the above comments are entirely my own \ ! "So your father was a woman" - "No No ROMAN (crack) Argh!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh ! ! Scotland ! \_____________________________________________________________________________/
woodside@ttidca.TTI.COM (George Woodside) (06/15/89)
In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: ...[edited] >Sversion() only gives the version number for GEMDOS, and that didn't >change between original ROMs and Mega ROMs. The TOS version number is >available as the second word of the OS header, whose address can be >found at _sysbase, $4f2. The GEMDOS version is changed with the release of TOS 1.4, I see from and earlier posting. So, when software wishes to take advantage of TOS 1.4 features (such as the improved file selector), should the feature be enabled via the Sversion call, or a check of the OS header? -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside
apratt@atari.UUCP (Allan Pratt) (06/16/89)
In article <2637@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: > In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > >NEVER NEVER NEVER use an absolute address like $FC0000 because if we > >ever move the ROM start address (HINT HINT) your program won't work! The > >only absolute addresses in any TOS program should refer to published > >system variables or hardware things like interrupt vectors. > > Your not thinking of moving the I/O addresses are you? Sorry, you're right, the I/O space is definitely nailed down. That is, any machine with, say, a Mega-style real time clock will have that clock chip address at the same place as on a Mega. That goes for all I/O devices: if the hardware acts like an ST, it'll address like an ST. Things which aren't in future machines will, of course, not be there, and nothing funny will address at the same place. Things which are different will address at a different place. Things which are both the same and different (i.e. new features, but have a compatibility mode) will address both ways. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
apratt@atari.UUCP (Allan Pratt) (06/17/89)
In article <4601@ttidca.TTI.COM> woodside@ttidcb.tti.com (George Woodside) writes: > In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > ...[edited] > >Sversion() only gives the version number for GEMDOS, and that didn't > >change between original ROMs and Mega ROMs. The TOS version number is > >available as the second word of the OS header, whose address can be > >found at _sysbase, $4f2. > > The GEMDOS version is changed with the release of TOS 1.4, I see from > and earlier posting. > > So, when software wishes to take advantage of TOS 1.4 features (such as > the improved file selector), should the feature be enabled via the > Sversion call, or a check of the OS header? > -- > *George R. Woodside - Citicorp/TTI - Santa Monica, CA > *Path: ..!{philabs|csun|psivax}!ttidca!woodside You should use the version number appropriate to what you're up to. If you want to know if you have the new file selector, you definitely should NOT check the GEMDOS version number. AES and GEMDOS are not inseparable. Check the AES version number (it has one) or the OS version number (described above). You could check the GEMDOS version number to see, for example, if a Dfree() call will take all day or not (old ones do, new ones don't). It is possible to have new GEMDOS but not new anything else (e.g. with a RAM-loaded GEMDOS, currently only used for internal development). It's best not to tie unrelated things, like the GEMDOS version number and the file selector, together. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt