🚀 go-pugleaf

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