bryan@ihnet.ATT.COM (b. k. delaney) (08/15/88)
There is a very simple solution to the problem of fixing things in the ROMS that cause bad programs to break. If you have a program that does not work with the old version of the OS then boot from Floppy the old version of the OS and use your program!! Remember the Original 520ST came with a floppy that booted in the OS Bryan DeLaney AT&T Bell Laboratories Naperville, IL
rich@lakesys.UUCP (Rich Dankert) (08/16/88)
In article <635@ihnet.ATT.COM> bryan@ihnet.ATT.COM (b. k. delaney) writes: > >There is a very simple solution to the problem of fixing things in >the ROMS that cause bad programs to break. > >If you have a program that does not work with the old version of the OS >then boot from Floppy the old version of the OS and use your program!! > >Remember the Original 520ST came with a floppy that booted in the OS One thing that one *must remember here though. Although one can boo ththe old rom from floppy, that does not mean the program will work. I have the Blit roms installed in my machine, and although say a program bombs with say 4 bombs, when I boot the TOS on disk, and then run the program, I get 2 bombs, er mushrooms... One comes immediatley to mind, say ST Accounts. Also remember that many are self booting disks, and don't always blow GEM\TOS out of the machine. > > Bryan DeLaney > AT&T Bell Laboratories > Naperville, IL rich..... UUCP: {uwvax}!uwmcsd1!lakesys!rich -- Disclaimer: The words, expressions posted here are my own..... Nothing is ever so bad that it can't be made worse by trying to fix it -- Law of the Hacker
rosenkra@Alliant.COM (Bill Rosenkranz) (08/16/88)
---
In article <635@ihnet.ATT.COM> bryan@ihnet.ATT.COM (b. k. delaney) writes:
->There is a very simple solution to the problem of fixing things in
->the ROMS that cause bad programs to break.
->
->If you have a program that does not work with the old version of the OS
->then boot from Floppy the old version of the OS and use your program!!
->
-> Bryan DeLaney
-> AT&T Bell Laboratories
-> Naperville, IL
now why didn't our friends at atari think of that? all they would have to do
is provide a floppy boot disk with the new ROMs containing (say) the 11/20/85
OS or the mega os. they could even make another incremental profit by charging
(say) $10-15 for the floppy (if the person ordering wanted it). it shouldn't
take more than a man month to put the os on a bootable floppy and maybe
another man month to test. i suspect they really didn't fix anything or
they just don't have the marketing saavy :^).
good suggestion...hope atari is listening...
-billrosenkra@Alliant.COM (Bill Rosenkranz) (08/17/88)
---
In article <635@ihnet.ATT.COM> bryan@ihnet.ATT.COM (b. k. delaney) writes:
->There is a very simple solution to the problem of fixing things in
->the ROMS that cause bad programs to break.
->
->If you have a program that does not work with the old version of the OS
->then boot from Floppy the old version of the OS and use your program!!
->
-> Bryan DeLaney
-> AT&T Bell Laboratories
-> Naperville, IL
now why didn't our friends at atari think of that? all they would have to do
is provide a boot disk along with the new ROMs containing (say) the 11/20
OS or the mega os. they could even make another incremental profit by charging
(say) $10-15 for the floppy (if the person ordering wanted it). it shouldn't
take more than a man month to put the os on a bootable floppy and maybe
another man month to test. i suspect they really didn't fix anything or
they just don't have the marketing saavy :^).
good suggestion...hope atari is listening...
-billnews@SJ.ATE.SLB.COM (USENET News System) (08/17/88)
In article <635@ihnet.ATT.COM> bryan@ihnet.ATT.COM (b. k. delaney) writes: > >There is a very simple solution to the problem of fixing things in >the ROMS that cause bad programs to break. > >If you have a program that does not work with the old version of the OS >then boot from Floppy the old version of the OS and use your program!! > >Remember the Original 520ST came with a floppy that booted in the OS From: greg@bilbo (Greg Wageman) Path: bilbo!greg Yes, but not all of us have the OS on disc. I know that I don't; my 1040ST came only with BASIC when bought about a year and a half ago. But you're right; Atari could release the 'fixed' version in ROM for new machines and retrofits, and provide the old version on a floppy disk, so that users could boot the appropriate version for the software they wish to use. This is a pain, admittedly, but Macintosh users seem to cope (there are some programs which run with only certain versions of System/Finder). The OS-on-disc eats into user memory too, don't forget. But it seems like a good way to get the fixes everyone wants into the ROMS without undue hardship to the writers of "misbehaved" software. They could even supply the proper OS on their release discs, with Atari's permission and cooperation, of course. Are you listening, Mr. Good?
leo@philmds.UUCP (Leo de Wit) (08/19/88)
In article <635@ihnet.ATT.COM> bryan@ihnet.ATT.COM (b. k. delaney) writes: > >There is a very simple solution to the problem of fixing things in >the ROMS that cause bad programs to break. > >If you have a program that does not work with the old version of the OS >then boot from Floppy the old version of the OS and use your program!! This will work ... a bit. It's OK if your program takes a long time to run (read: it is worth the effort to reboot). It is a problem if you have an environment in which you want several programs to run (and you can't afford to reboot each time) of which some old ones are bad in the above sense and some new ones are broken by the OLD TOS and/or GEM (remember it wasn't perfect, to use an euphemism 8-). >Remember the Original 520ST came with a floppy that booted in the OS Sure I do. Some of the more annoying problems were 1) the buggy memory allocation: after having started a number of programs from the desktop you couldn't open a floppy disk icon anymore. I think the problem was in the desktop. 2) problems with eight character folder names. When I created a folder whose name consisted of 8 characters all files put into the folder magically vanished. Also floppies from a friend that had this type of folder names couldn't be read (the folder seemed empty). Maybe Atari should redistribute an improved O.S. (e.g. the one current in the ROMs) on floppy together with the new ROMs. Or (alternative solution) have code in the ROMs for both old and new programs (triggered by the date of the program); the flag old prog/new prog could be set by Pexec and put into the basepage, to be picked up by GEMDOS calls. Leo.
hase@netmbx.UUCP (Hartmut Semken) (08/21/88)
In article <383@snjsn1.SJ.ATE.SLB.COM> greg%sentry@spar.slb.com (Greg Wageman) writes: >In article <635@ihnet.ATT.COM> bryan@ihnet.ATT.COM (b. k. delaney) writes: >> >>There is a very simple solution to the problem of fixing things in >>the ROMS that cause bad programs to break. >> >>If you have a program that does not work with the old version of the OS >>then boot from Floppy the old version of the OS and use your program!! Or just release the fix on disk: a little residend program replacing the original (ROM-) trap handler. This would be my way of releasing a fix; if it works and everybody likes it, put it in a new ROM set. Another solution would be a set of big ROMs containing both versions of the system. I put 6*27C512 in my 520ST+ to have the "old" and Blitter TOS availeble; this is kind of expensive but useful... hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP If there is something more important than my ego, I want it caught and shot, NOW! (Zaphod Beeblebrox)
gert@nikhefh.hep.nl (Gert Poletiek) (08/22/88)
In article <1224@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: > >Or just release the fix on disk: a little residend program replacing the >original (ROM-) trap handler. >This would be my way of releasing a fix; if it works and everybody likes >it, put it in a new ROM set. > >Another solution would be a set of big ROMs containing both versions of >the system. >I put 6*27C512 in my 520ST+ to have the "old" and Blitter TOS availeble; >this is kind of expensive but useful... > >hase >-- >Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP >If there is something more important than my ego, I want it caught and shot, >NOW! (Zaphod Beeblebrox) I wouldn't like that! Just imagine what happens when one happens to have 5 fixes on GemDos. level 1 trap handler if not pathed call goto old trap else do own stuff return level 2, 3, 4, 5 same This means that in order to get the 5th trap patch activated the system call from a user program has to traverse FIVE trap handlers. This takes lots of time. Even with an efficient trap handler like the one in GemDos one does not want to loose that processing time (grin) Look at the way things are organized in the Macintosh OS. All system traps are routed by a trap address table (just like in GemDos). The subtle difference with GemDos is that the trap address table is located somewhere in RAM, not ROM. (Well, it is copied from ROM to RAM at system boot time). The Mac OS has two calls (GetTrapAddress and SetTrapAddress) which get and set a trap vector in the traps table (resp). Organized this way one does not loose a single clock cycle when a program calls a OS service that happens to be patched. Moreover, for Atari this method is very convenient to test and distribute patches on a regular basis. (Oh well, 3 years is regular but I mean regular with a slightly higher frequency). Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet From september 1st 1988: Gert Poletiek Dept. of Math. and Computing Science, University of Amsterdam, Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!uva!gert bitnet: uva!gert@mcvax.bitnet, U00025@hasara5.bitnet
koreth@ssyx.ucsc.edu (Steven Grimm) (08/23/88)
In article <524@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: >Look at the way things are organized in the Macintosh OS. All system traps >are routed by a trap address table (just like in GemDos). The subtle >difference with GemDos is that the trap address table is located somewhere in >RAM, not ROM. (Well, it is copied from ROM to RAM at system boot time). The ST's trap vectors are in RAM, too. In fact, I don't know of *ANY* 68xxx box that doesn't have them in RAM. Their locations are down in low memory ($60 or thereabouts, I don't remember exactly...) You have to be in supervisor mode to write to them, but they can certainly be changed. I've done it lots of times. >The Mac OS has two calls (GetTrapAddress and SetTrapAddress) which get and >set a trap vector in the traps table (resp). Try looking up Setexc() in your XBIOS manual. --- These are my opinions, and in no way reflect those of UCSC, which are wrong. Steven Grimm Moderator, comp.{sources,binaries}.atari.st koreth@ssyx.ucsc.edu uunet!ucbvax!ucscc!ssyx!koreth
gert@nikhefh.hep.nl (Gert Poletiek) (08/24/88)
In article <4582@saturn.ucsc.edu> koreth@ssyx.ucsc.edu (Steven Grimm) writes: >In article <524@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: >>Look at the way things are organized in the Macintosh OS. All system traps >>are routed by a trap address table (just like in GemDos). The subtle >>difference with GemDos is that the trap address table is located somewhere in >>RAM, not ROM. (Well, it is copied from ROM to RAM at system boot time). > >The ST's trap vectors are in RAM, too. In fact, I don't know of *ANY* 68xxx >box that doesn't have them in RAM. Their locations are down in low memory >($60 or thereabouts, I don't remember exactly...) You have to be in supervisor >mode to write to them, but they can certainly be changed. I've done it lots >of times. > >>The Mac OS has two calls (GetTrapAddress and SetTrapAddress) which get and >>set a trap vector in the traps table (resp). > >Try looking up Setexc() in your XBIOS manual. > >--- >These are my opinions, and in no way reflect those of UCSC, which are wrong. >Steven Grimm Moderator, comp.{sources,binaries}.atari.st >koreth@ssyx.ucsc.edu uunet!ucbvax!ucscc!ssyx!koreth OK, OK I did not make my point very clear. (And Yes, I do know 680X0 boxes that have their trap handler addresses in a ROM). What I meant is this: In the Macintosh OS calls are implemented by whole lotta line A trap numbers. This takes one single word in a program in order to call the OS. The trap word looks like 0xaXXX, where the XXX represent the number of the system call actually requested by the caller. It is this 12 bit number that is used as index into an array of pointers THAT'S THE TRAP ROUTINE ADDRESS TABLE I MEANT IN THE ORIGINAL POSTING. This array of pointers to OS routines is located in RAM on the Macintosh. So what the OS routines GetTrapAddress and SetTrapAddress actually do is returning (for Get) an entry from the array of function pointers or modifying (for Set) one single entry in this array. FLAME ON Of course I know the Setexc() call: but its essentially different from Get/SetTrapAddress in the Mac! FLAME OFF The whole idea behind all this is that they (Apple) can now apply patches to roms from the 'system' file. (I think it's the PTCH resources in it). They don't have to order a whole new shipment of ROMS when a bug is discovered. They can just replace the erroneous OS routine. If Atari would do things this way (and I doubt there is any look/feel involved) you could easily work with different versions of Malloc() in the same system. Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet From september 1st 1988: Gert Poletiek Dept. of Math. and Computing Science, University of Amsterdam, Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!uva!gert bitnet: uva!gert@mcvax.bitnet, U00025@hasara5.bitnet
hase@netmbx.UUCP (Hartmut Semken) (08/25/88)
In article <524@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: >In article <1224@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: >> >>Or just release the fix on disk: a little residend program replacing the >>original (ROM-) trap handler. >>This would be my way of releasing a fix; if it works and everybody likes >>it, put it in a new ROM set. >>I put 6*27C512 in my 520ST+ to have the "old" and Blitter TOS availeble; >>this is kind of expensive but useful... >>Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP >>If there is something more important than my ego, I want it caught and shot, >>NOW! (Zaphod Beeblebrox) > >I wouldn't like that! Just imagine what happens when one happens to have >5 fixes on GemDos. Yea. Thats the point. Today, I have two sets of ROMs (MEGA and pre-Mega) switchble and one "patch" loaded to RAM (Turbodos; I like it.) The RAM loaded patches can only be an intermediate fix for a ROM based system. But isn't it a great way to release a fix for field-testing? The best fix seems to be a new operating system, right? Let's complain a little more about the heap of shit the st seems to be! Maybe the next company dropping the st is Atari.... No. I'm doing serious work with my st. I do dislike to loose some time writing my own little programs, because the OS behaves a little "strange", but I (*I*) can live with it (almost :-) hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP If there is something more important than my ego, I want it caught and shot, NOW! (Zaphod Beeblebrox)
wes@obie.UUCP (Barnacle Wes) (08/25/88)
In article <530@nikhefh.hep.nl>, gert@nikhefh.hep.nl (Gert Poletiek) writes: > If Atari would do things this way (and I doubt there is any look/feel > involved) you could easily work with different versions of Malloc() in the > same system. Gert, you have missed the point. You can easily patch GEMDOS, BIOS, or XBIOS functions on the ST - the new routine saves the original trap address, installs itself as the trap handler. Whenever it is called, it checks to see if the function number is the one it handles, and if not, passes the call off to the original vector. This can be done via a program in the \AUTO folder, even. This is not quite as elegant as the Line A trap, but it does work, and the Line A & F traps were designed for other reasons. On the '020 and '030, Line A opcodes are MMU ('851 for the '020, built-in on the '030) instructions, and Line F opcodes are FPU ('881 or '882) instructions. -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein --
KEITH@SYSD.SALFORD.AC.UK (Keith Wolstenholme) (08/26/88)
Atari already went down this route once, when the XLs were introduced they weren't 100% compatible with the older machines but they did have RAM located "underneath" the OS ROMS. Various translator disks were produced that turned off the OS in ROM and loaded the older OS into RAM. When the ST was introduced the OS was on disk but was moved to ROM to save memory in the limited 512K available. With larger memories perhaps its time for a move back to this system at least for intermediate fixes/upgrades and to enable users to load older ill-behaved software. I, owning a MEGA ST2 with blitter, could use a disk based, pre-blitter OS that would turn off the blitter and give the option of booting other software before attempting to initialise the desktop. Would the original OS do this ? If so how can I get hold of a copy ? (I haven't seen it in any PD lists). Maybe only a small patch would be needed ? Releasing new upgrades/fixes this way would have benefits for Atari too. They would have the best chance to sort out any bugs before taking the expensive step of commiting yet another buggy OS to silicon !! JANET keith@uk.ac.salford.sysd ARPA: keith@sysd.salford.ac.uk UUCP: ..ukc!sysd.salford.ac.uk!keith PHONE: +44 61 737 7010 POST: 3-S, Computer Centre, Salford University, Salford, M5 4WT, U.K.
rich@jolnet.ORPK.IL.US (Rich Andrews) (08/27/88)
In article <KW.D6XG.260888@SALF.D> KEITH@SYSD.SALFORD.AC.UK (Keith Wolstenholme) writes: > >Atari already went down this route once, when the XLs were introduced >they weren't 100% compatible with the older machines but they did have >RAM located "underneath" the OS ROMS. Various translator disks were >produced that turned off the OS in ROM and loaded the older OS into >RAM. > The XL operating systems WERE 100% (or nearly so) compatable with the old OS in the Atari 800/400's. It was the illegal system calls written in by the "Software Engineers" at various companies that caused all the grief. And what about those cases where you absolutely had to make an illegal system call? There is a quasi-legal way to do it. Check the sources for the XEP-80. If you need more info I can state case after case where the authors of some well known pieces of software have made illegal calls to the OS. rich andrews -- Any opinions expressed are my own. Now, for a limited time, they can be yours too, for the incredible price of only $19.95. Simply send $19.95 (in Alterian dollars) to ...killer!jolnet!rich or rich@jolnet.orpk.il.us.
uace0@uhnix2.uh.edu (Michael B. Vederman) (08/27/88)
Perhaps the most confusing point about your posting is calling a LINE A
*exception* a *TRAP* call. All 680x0 boxes have *TRAP* vectors staring at
HEX $50. The ST actually uses LINE F for GEM calls, and LINE A for low
level screen BLT routines.
Of course, Motorola specificaaly reserved LINE F for math calls in the 68881
I believe.
But teh original intent of your message, in other words, document location and
a method for returning and changing these locations, would be a nice touch.
I believe tho, if you pass an illegal function number to one of the trap
handlers (1, 13, 14) you get a pointer to the function table in A0. This is
not documented that I know of, and is more or less a side-effect of passing
an illegal function number. Of course, it is trivial at this point to get
a pointer to the desired routine, but nothing is standardized then.
- mike
--
for (;;) : Use ATARINET, send an interactive
do_it(c_programmers); : message such as:
: Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACEleo@philmds.UUCP (Leo de Wit) (08/28/88)
In article <656@uhnix2.uh.edu> uace0@uhnix2.UUCP writes: [some lines deleted]... >But teh original intent of your message, in other words, document location and >a method for returning and changing these locations, would be a nice touch. This is also simple to implement. Just keep the tables in RAM. >I believe tho, if you pass an illegal function number to one of the trap >handlers (1, 13, 14) you get a pointer to the function table in A0. This is >not documented that I know of, and is more or less a side-effect of passing >an illegal function number. Of course, it is trivial at this point to get >a pointer to the desired routine, but nothing is standardized then. If you use more than one patch, using the original vector in ROM will fail (the first patch applied will never be executed). The method I use is simple and 'patch-compatible': save the old vector (of the trap) in your resident program. Anything that this program shouldn't handle (most things) are vectored through the old vector. This might be just a little bit slower (in the old code the function number parameter gets checked again and so) but it allows for more than one patch. It is also less likely to get into trouble with new ROM releases - it's probably not even documented that there IS a function table (although my ROM also passes your A0 test 8-). Leo.
gert@nikhefh.hep.nl (Gert Poletiek) (08/29/88)
In article <169@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <530@nikhefh.hep.nl>, gert@nikhefh.hep.nl (Gert Poletiek) writes: >> If Atari would do things this way (and I doubt there is any look/feel >> involved) you could easily work with different versions of Malloc() in the >> same system. > >Gert, you have missed the point. You can easily patch GEMDOS, BIOS, or >XBIOS functions on the ST - the new routine saves the original trap >address, installs itself as the trap handler. Whenever it is called, it >checks to see if the function number is the one it handles, and if not, >passes the call off to the original vector. This can be done via a >program in the \AUTO folder, even. > >This is not quite as elegant as the Line A trap, but it does work, and >the Line A & F traps were designed for other reasons. On the '020 and >'030, Line A opcodes are MMU ('851 for the '020, built-in on the '030) >instructions, and Line F opcodes are FPU ('881 or '882) instructions. > >-- > {hpda, uwmcsd1}!sp7040!obie!wes > "Happiness lies in being priviledged to work hard for > long hours in doing whatever you think is worth doing." > -- Robert A. Heinlein -- NO NO NO NO NO NO, installing a trap handler is exactly what I DON'T want to happen. I pointed out already several times that when one bug is fixed, one extra traphandler is installed, when two bugs are fixed two extra trap handlers are installed, and so forth. All these trap handlers checking for the correct system call number to fix take TIME. Fixing things in a way a la the Mac does not take ANY extra time. Bugs are generally not discovered all at the same time. So its reasonable to assume that several fix files would be present. Installing these by taking the original 68000 trap handler over just takes too much time while performing lots of system calls. Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet From september 1st 1988: Gert Poletiek Dept. of Math. and Computing Science, University of Amsterdam, Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!uva!gert bitnet: uva!gert@mcvax.bitnet, U00025@hasara5.bitnet
apratt@atari.UUCP (Allan Pratt) (08/30/88)
The other point that Gert and others miss when they talk about replacing OS routines is the close coupling WITHIN THE OS between, say, Malloc and the process handler. You can't just rip out Malloc and change it because other parts of the OS depend on it being exactly as it is. That doesn't mean the OS is a monolith; it's not (much). But some crucial data structures pervade the whole thing, and others are tightly coupled among a few modules. Somebody else asked this same question about Pexec, and the answer is the same: it's tightly coupled with other parts of the OS (not just Malloc). ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
chasm@killer.DALLAS.TX.US (Charles Marslett) (09/01/88)
In article <731@jolnet.ORPK.IL.US>, rich@jolnet.ORPK.IL.US (Rich Andrews) writes: > In article <KW.D6XG.260888@SALF.D> KEITH@SYSD.SALFORD.AC.UK (Keith Wolstenholme) writes: > > > >Atari already went down this route once, when the XLs were introduced > >they weren't 100% compatible with the older machines but they did have > >RAM located "underneath" the OS ROMS. Various translator disks were > >produced that turned off the OS in ROM and loaded the older OS into > >RAM. ... > The XL operating systems WERE 100% (or nearly so) compatable with the old OS in the Atari > 800/400's. It was the illegal system calls written in by the "Software Engineers" at various > companies that caused all the grief. > rich andrews I had a bit of experience in that area (the Apex HP Calculator program actual did a JSR into the middle of an instruction in the floating point ROM -- and of course if you change the code to speed it up, that is one of those things most programmers will overlook!). But to get back on track, all the discussion so far on the problems Atari is trying to face with this upgrade of TOS ROMs are in fact illegal system calls (or accesses generally) and really should not have ever been released by whomever wrote the code... They were though, so now we have to decide what to do next --- live with a chunk of trash in the ROMs or throw it out (and with it yesterday's funnies, since someone wrapped the catbox contents in them before I read them !!! I can live with either decision, but the stink lasts a lot longer than the pain of lost gratification this month. Charles Marslett chasm@killer.dallas.tx.us