Path: utzoo!utgpu!attcan!uunet!mcvax!hp4nl!philmds!prle!cstw01!meulenbr From: meulenbr@cstw01.UUCP (Frans Meulenbroeks) Newsgroups: comp.sys.atari.st Subject: Re: A scheme for updating/patching gemdos Message-ID: <190@cstw01.UUCP> Date: 2 Sep 88 08:34:09 GMT References: <3377@crash.cts.com> <1148@atari.UUCP> Reply-To: meulenbr@cstw01.UUCP (Frans Meulenbroeks) Organization: Centre for Software Technology, Philips Eindhoven Lines: 64 In article <1148@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >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