[comp.sys.amiga] 68010+68881 boards

david@ms.uky.edu (David Herron -- Resident E-mail Hack) (12/18/87)

There's been some discussion in sys.att recently about getting
68881 co-processor's installed into the 7300/3b1.  To forestall
misinformation, there is such a gadget listed in the parts list
for the 7300, and AT&T developed the product, but in a flash of
brilliance never marketed it.

Weell..  I vaguely recall that 68000's are pin compatible with 68010's,
(is that right?  if not, then stop me now)..  Also, there are companies
selling daughter boards for Amiga's which allow you to plug in
a 68010+68881 in replacement for the 68000 that comes in the machine.

SO

Would such a board also work in a 3b1?

In general, are there boards available which'd do something like
this for a 3b1?  (I'd really like to get a 68881 into my 3b1).

-- 
<---- David Herron -- The E-Mail guy            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- Winter health warning:  Remember, don't eat the yellow snow!

mph@rover.UUCP (Mark Huth) (12/22/87)

In article <7883@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes:
...
>Weell..  I vaguely recall that 68000's are pin compatible with 68010's,
There has been quite a lot of talk about '010 vs. '000 and '881/'882.

I'd like to take just a little net time to share some of the facts
about this area, at least as I see them.

the 68010 is electrically pin-compatible with the 68000 (assuming they
are in the same package :-) ).  The only direct software
incompatibility is the move sr,dn instruction, which will cause a
priviledge trap on the 68010 if you are not in supervisor mode.  This
is easily remedied in most situation by a program called DeciGEL which
is run at start-up time and installs a trap handler that emulates the
instruction for users in the 68010 systems.  I have had no problems
using a 68010 in my systems for over a year with the DeciGEL
installed.  Of course, I don't play protected game software on my
machines, so I can't comment on $&%^ copy protection schemes.

The 68010 is 30-40% faster than a 68000 in the hardware multiply and
divide instructions, and occasionally a cycle of two faster on some
other instructions - not a big deal.  It does have pre-fetch pipe
which is deep enough to accomodate an auto index move instruction and
a DBRA instruction - thus allowing very rapid memory to memory moves.
After the first execution of the loop, the pipe has all of the
instructions pre-fetched, so only data space bus cycles are performed.

The 68010 processor was produced to be used in virtual memory systems.
Unlike the 68000, the 68010 stacks enough information for the software
to restart a process following a bus exception.  Additionally, the
68010 contains an Vector Base Register, allowing relocation of the
exception vectors to arbitrary page boundaries, making task management
more straightforward on the 68010 (ie. each task can have its own set
of exception vectors.)  Also, the 68010 has a couple of registers to
allow the specification of the source and destination memory spaces,
faciliting the supervisors loading of user code into protected
memories.  It turns out that these last couple of registers greatly
facilitate emulation of the co-processor interface by the 68010, which
is why most people offering 68881 boards also include the 68010.
Without the memory space control, special hardware would be needed to
allow the 68000 to access the coprocessor space of the memory.  (not
strictly true, there would be other ways, but each would comprimise
the Motorola model of the memory space.  Briefly, in addition to the
16 Mbyte memory space, there are 3 additional bits which specify which
memory map is being referenced - user program/data, supervisor
program/data, and cpu space are all currently defined by Motorola.
These are the FC0..FC2 signals on the processor bus.  The first four
are self-evident, but CPU space is interesting.  CPU space is used
for interrupt acknowledge cycles, breakpoint acknowledge cycle ('020+)
and co-processor cycles.)

Enough for now.

Mark Huth