Path: utzoo!utgpu!water!watmath!clyde!att!alberta!ubc-cs!uw-beaver!mit-eddie!bbn!uwmcsd1!marque!uunet!mcvax!hp4nl!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: To Fix or Not To Fix (Really: applying patches to OS)
Message-ID: <772@philmds.UUCP>
Date: 28 Aug 88 06:55:39 GMT
References: <635@ihnet.ATT.COM> <383@snjsn1.SJ.ATE.SLB.COM> <1224@netmbx.UUCP> <524@nikhefh.hep.nl> <4582@saturn.ucsc.edu> <530@nikhefh.hep.nl> <656@uhnix2.uh.edu>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 26

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.