Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!fluke!fletch
From: fletch@fluke.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: a 68010 for your st?
Message-ID: <574@tc-fletch.tc.fluke.COM>
Date: Thu, 12-Mar-87 19:05:51 EST
Article-I.D.: tc-fletc.574
Posted: Thu Mar 12 19:05:51 1987
Date-Received: Fri, 13-Mar-87 21:19:50 EST
References: <8703062012.AA22292@ucbvax.Berkeley.EDU>
Distribution: world
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 37

In article <8703062012.AA22292@ucbvax.Berkeley.EDU> LINDAHL%BRANDEIS.BITNET@forsythe.stanford.edu writes:
>i'm on spring break, and since i have nothing better to do i was thinking
>of hooking up a 68010 to my st. yes, it's a disgusting hack from the hardware
>side... i was wondering: has anyone else done this? what software problems
>do you have other than MOVE SR,<ea> (fixable by grabbing the priv violation
>vector)?
>
>i know that the different stack frames will probably clobber my favorite
>debugger, but after looking into the st bios i don't think that it ever
>looks at the stack frame except for the bomb handler, which doesn't care what
>kind of stack frame it is.
>
>comments anyone?
>
I have taken the first step of the installing a 68010 in place of the 68000;
I simply swapped microprocessor chips.  TOS (dated 11-20-1985 in code) will
not boot with the 68010.  I observed both bus errors and privilege violations.

When I have the ability to make cartridges, I plan on making a cartridge to
allow TOS to run on the 68010.  The vector base register will allow all
exceptions to be intercepted, even if apps redefine the vectors.

The idea is to intercept all vectors, handle group 0 exeptions (bus error,
address error and reset) and emulate the MOVE from SR instruction.

TOS may make this difficult.  It appears that not all exception returns are
done with the RTE instruction, but some are.  The extra word on the stack
(extra 23 words for bus errors) cannot be played with unless it is known
how TOS will return from the exception.

The benefits of the 68010 would be faster multiple/divide times, pre-fetch
and a fast loop mode.  The loop mode would be nice for things like clearing
memory.  I am disappointed that the code in ROM was not written in a way to
be compatible with the 68010 chip.  Apparenty the Amiga OS was.

I would be interested in mail from others who have looked at something like
this or have comments/warnings/dire predictions.  Simple fixes always welcome.