🚀 go-pugleaf

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