gert@nikhefh.hep.nl (Gert Poletiek) (08/24/88)
I seem to have created a bit of confusion with my posting to this group
on how system calls may be patched in GemDos if Atari were to adopt a
slightly modified system call trap handler.
In my original posting on this subject I referred to the method used in the
operating system of the Macintosh. Let me explain how this method works.
Assumptions: 68000 (or 68070) system (not an 68010/20/30)
Rom located at addresses 0x0 through 0x7 at reset time and
shortly thereafter (reset program counter and initial supervisor
mode stack pointer are fetched from these addresses)
Ram locations 0x8 and up
Operating system in Rom somewhere high up in memory.
This description fits
the Atari 520, 1040, Mega 2 and 4, and
the Macintosh 512K, Plus and SE.
A user program may call the operating system for some service by issuing the
appropriate trap call (i.e. on the ST trap 14 for Xbios, 13 for Bios, trap 1
for GemDos and trap 2 for GEM; and one of the lineA emulator calls on the
Macintosh).
All these calls cause the 68000 to fetch an exception processing vector (the
address at which the OS trap dispatcher starts) from low memory in the
address range 0x8 throug 0x3ff. The address from which the exception vectors
are fetched are fixed on the 68000 (though not on the 680[12]0 which have a
register called the Vector Base Register which holds the start address of the
exception vector table).
On the Atari ST the process calling the OS must have pushed an operation code
for the requested system call onto the active stack prior to executing the
trap. This operation code (the number of the system call) is used as an index
into a table of addresses. This table holds the addresses of the first
instruction for each system call. Hence the assembler code in the OS
dispatcher could look something like this (oversimplified):
OSEntryPoint:
move.w opCode(sp),d0 # get operation code
lea dispatchTable,a0 # get dispatch table address
movea.l (a0,d0.w),a0 # get pointer to requested function
jsr (a0) # jump to requested function
<do cleanup and return to caller>
On the Macintosh user programs do not issue a trap instruction to get to the
operating system. Instead they incorporate an unimplemented 68000 instruction
into their program. This unimplemented instruction starts with 0xa and is 16
bits wide. The lower 12 bits of that word encode the number of the system
call (hence the Mac may have 16 times as many system calls tied to the same
exception vector as the ST). Whenever the unimplemented instruction (line A
instruction) is executed (well, only decoded by the 68000 instruction
decoding logic) the 68000 starts exception processing in much the same
(though not exactly the same) way as when a trap instruction is executed.
The Macintosh operating system uses (schematically) the same trap dispatcher
routine as the ST. The ONLY difference is the address of the 'dispatchTable'
variable shown in the assembly example above.
On the ST the dispatchTable is located in ROM, on the Macintosh it is located
in RAM (low memory address). Sure, its safer to have the dispatchTable in
ROM, you would say. True, it cannot be overwritten by a program going nuts.
However, having the dispatchTable in ROM has one major drawback (and,
consequently, having it in RAM has an advantage).
When an operating system routine is found to contain a bug (e.g. Malloc and
others on the ST) and the dispatchTable is located in RAM it is quite easy to
fix the erroneous routine.
During system startup a patch for the erroneous routine could be read from
disk and be applied by placing the new routine in RAM and have the
appropriate pointer from the dispatchTable point to the newly loaded routine
instead of the erroneous one in ROM.
On the Macintosh two routines exist to manipulate the dispatchTable. They
are: GetTrapAddress and SetTrapAddress. GetTrapAddress is used to get the
start address for a certain system call service routine from the
dispatchTable. SetTrapAddress is used to change the value of one of the
entries in the dispatchTable. SetTrapAddress is used by the resources of type
'PTCH' in the Macintosh 'System' file, which are loaded into memory as soon
as the system is bootstrapped. Normally (at least in the more recent versions
of the System file), there are PTCH resource for all kinds of Macs: the
patches may be applied to different roms (remember there are 3 differently
sized roms in Macs: 64KB(old Macs), 128KB(Plus and SE) and 256KB (MacII)) and
to different rom releases (there are at least three different rom releases
for the 128KB version alone) and for different hardware configuarions (Note
that the Plus, SE and II have an NCR SCSI controller while the older 512K Mac
does not). In each case the PTCH resource, once loaded into RAM, finds out
all it needs to know for deciding whether or not to apply the patch.
All this is made possible by one simple fact: the dispatchTable is located in
RAM.
With my original posting I intended to explain this to the net, and I wish
that Atari would adopt such a scheme in the next ROM release. It makes
upgrading the OS so much easier since you don't need to ship new roms every
once in a while when a bug is found...
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.bitnetsreeb@pnet01.cts.com (Ed Beers) (08/30/88)
After reading lots of messages on the merits of using the 0xAxxx
***RESERVED*** instruction trap, I have to add my 2 cents. Using the 0xAXXX
or 0xFXXX traps is bad news. It limits compatibility with future 68000 family
products. Apple atleast avoided using the 0xFXXX trap which is why they have
had 68881 support for sometime while we still only have somewhat kludged,
semi-supported floating point support much less a 68020/68030 version of the
ST. If you want to have pointers for each routine, it wouldn't add many
instructions to use a legal trap and vector in software.
UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!sreeb
ARPA: crash!pnet01!sreeb@nosc.mil
INET: sreeb@pnet01.cts.comapratt@atari.UUCP (Allan Pratt) (09/01/88)
In article <3377@crash.cts.com> sreeb@pnet01.cts.com (Ed Beers) writes: > After reading lots of messages on the merits of using the 0xAxxx > ***RESERVED*** instruction trap, I have to add my 2 cents. Using the 0xAXXX > or 0xFXXX traps is bad news. It limits compatibility with future 68000 family > products. Apple atleast avoided using the 0xFXXX trap which is why they have > had 68881 support for sometime while we still only have somewhat kludged, > semi-supported floating point support much less a 68020/68030 version of the > ST. Don't be silly. Using line-F has nothing to do with upward mobility of the ST to 68020/68030, because such machines will have more ROM space, so Line-F won't be necessary. It does make plugging a 68020 into an ST tough, but that's already tough because of stack frame differences. Somebody in Germany did it... I don't know how they got rid of Line-F and still crammed the OS into 192K of ROM, but they did. Motorola explicitly reserved the $Axxx instructions for machine-specific use (as opposed to "reserved for Motorola use" like $Fxxx), so Atari isn't stepping on any toes there. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
koreth@ssyx.ucsc.edu (Steven Grimm) (09/01/88)
In article <1148@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >Somebody in Germany did it... I don't know how they got rid of Line-F >and still crammed the OS into 192K of ROM, but they did. Perhaps they used line-A instead? There can't be THAT many line-F traps -- certainly not enough that you couldn't use A100 and up instead (assuming that the documented line-A calls are the only ones that are used; but even if there are undocumented calls, I find it hard to imagine there being enough of them to stop this from working...) That seems like a nice clean solution to the problem to me. --- 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
meulenbr@cstw01.UUCP (Frans Meulenbroeks) (09/02/88)
In article <1148@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: <more includes deleted> >Don't be silly. Using line-F has nothing to do with upward mobility >of the ST to 68020/68030, because such machines will have more ROM space, >so Line-F won't be necessary. It does make plugging a 68020 into >an ST tough, but that's already tough because of stack frame differences. >Somebody in Germany did it... I don't know how they got rid of Line-F >and still crammed the OS into 192K of ROM, but they did. > >Motorola explicitly reserved the $Axxx instructions for machine-specific >use (as opposed to "reserved for Motorola use" like $Fxxx), so Atari >isn't stepping on any toes there. > I believe Allen is right on the line A stuff. Main problem putting an 68020 into an ST is tough because of stack frame differences. I caught this by setting a different vector base address, and rework the frame to an 68000 one. All rte's are changed to traps which recreate an 68020 frame, followed by rte. Another problem is line-F. Solution is easy: There are only 16 or so line-A codes used, and 3/4 of the available line-F codes. Just map (through a smart algorithm) all line F codes into unused line A codes. *** FLAME ON *** Now this is what Atari should have done in the first place. Line-F's are reserved and we all know for years why. *** FLAME OFF Luckily here's a fine chance to recover Allen: why not change this in TOS 1.4. This will make life more some people a lot easier, and, since people are already explicitly discouraged to call line-F directly, will not break a substantial amount of existing code. By the way: If you want to do the 68020 trick: there are also some timing loops which have to get a new value (due to caching etc). Also some self modifying code exists which needs a hack. Also programs which do a move to/from SR will break since this instruction became privileged. Just capture the exception and emulate it. I've hacked these things in the 11/20/85 disk TOS, and things seem to work I get a desktop, but some programs still fail. Sometimes timing loops seem to be the problem (as for AHDI). Don't expect too much performance gain though, since you have to use the 16 bit ST bus and the 8 Mhz ST clock. Other problem is that your gain is often comsumed by extra wait states added by the glue? to accomodate for synchronisation between 68000 and video. The main gain is due to the cache. Unrelated info: Nice work Allen, what you are doing with TOS 1.4. Keep things rolling. It seems that Atari is finally getting somewhere. Makes me proud to be an ST owder again. -- Frans Meulenbroeks Centre for Software Technology ...!mcvax!philmds!prle!cst!meulenbr or ...!uunet!prlb2!cst!meulenbr or perhaps meulenbr@cst.prl.philips.nl
VBRANDT@DBNUAMA1.BITNET (09/06/88)
In Info-Atari16 Digest #385, ssyx!koreth@ucbvax.Berkeley.EDU (Steven Grimm) writes: >In article <1148@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >>Somebody in Germany did it... I don't know how they got rid of Line-F >>and still crammed the OS into 192K of ROM, but they did. >Perhaps they used line-A instead? There can't be THAT many line-F traps -- >certainly not enough that you couldn't use A100 and up instead (assuming that >the documented line-A calls are the only ones that are used; but even if there >are undocumented calls ... This is exactly what they did, and no, there are no undocumented LineA traps. Bitnet: VBRANDT@DBNUAMA1 Volker A. Brandt UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt Angewandte Mathematik ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU (Bonn, West Germany)
VBRANDT@DBNUAMA1.BITNET (09/07/88)
In Digest #387, mcvax!hp4nl!philmds!prle!cstw01!meulenbr@uunet.uu.net (Frans Meulenbroeks) writes: >(...) Another problem is line-F. >Solution is easy: >There are only 16 or so line-A codes used, and 3/4 of the available >line-F codes. Just map (through a smart algorithm) all line F codes into >unused line A codes. >*** FLAME ON *** >Now this is what Atari should have done in the first place. >Line-F's are reserved and we all know for years why. >*** FLAME OFF >Luckily here's a fine chance to recover Allen: why not change this in >TOS 1.4. This will make life more some people a lot easier, and, since >people are already explicitly discouraged to call line-F directly, will >not break a substantial amount of existing code. I strongly second this: maybe A.Pratt et. al. could expand on their reasons why or why not to convert line F traps to line A ones in the forthcoming 1.4 release. Finally, thanks to the people at Atari for the increased quality and quantity of their postings to the newsgroup ! I really do appreciate that, since this newsgroup is my primary source of accurate and up-to-date info on the ST. (This, unfortunately, implies a flame directed at Atari Germany ...) Bitnet: VBRANDT@DBNUAMA1 Volker A. Brandt UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt Angewandte Mathematik ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU (Bonn, West Germany)