|
The replacement of a 68000 with a 68020 is not as simple as a plug adapter
to join the '020's PGA (pin grid array) to the 68000's DIP (dual in-line
pin) socket. There are hardware architecture differences that, while software
compatibility may be preserved, require some additional logic. The 68020
has a 32 bit data path to the outside world, and more address lines, and
a coprocessor interface, etc. There are also differences in the way memory
is accessed (hardware). There have been at least two articles in the trade
press on how to build an adapter, and the references have appeared in Byte's
'Best of Bix' column within the last year or so. I located one, and will
key it in, sans schematic diagram, below. I've copied the schematic, and
will send it to anyone who has a Digi-view and promises to post an IFF version.
from EDN, Jan. 9, 1986, reprinted without permission.
(now PLEASE don't steal this copy from the library)
================================================================================
68020 Adapter Upgrades 68000 Systems
by Brian Koga, Wang Labs., Lowell, MA.
By using a plug-in adapter board, you can replace a 16-bit 68000 CPU with
the 32-bit 68020 CPU, which offers a larger instruction set and faster program
execution. The resulting system requires some modification of operating
-system software but no additional hardware changes.
The adapter board plugs into the 68000 socket as an emulator does.
Because the 68020 can operate on a 16-bit data bus as well as a 32-bit
data bus, wiring modifications consist only of connecting D0 through D15
of the 68000 to D16 through D31 of the 68020 data bus. All other address
(A1 through A23) and control signals with corresponding names are wired
one for one; address lines A24 through A31 are unconnected.
The 68020 requires six additional signals: AVEC, E, VMA, LDS, UDS,
and DSACK1. AVEC, E, VMA, and DDSACK1 are generated with proper timing
relationships by logic gates on the adapter board. LDS and UDS are generated
by decoding the SIZ0, SIZ1, and A0 signals and qualifying them with DS.
Keep in mind that the two processors handle exception processing
differently. The 68020 stacks as many as 46 words during exception processing,
but the 68000 stacks only three words. In the worst case, the CPU will
halt if software doesn't compensate for this difference. Also, the 68020
generates the address strobe (AS) on the clock's falling edge (state 1),
but the 68000 generates AS on the rising edge (state 2). If your hardware
timing relies on the latter, you must invert the clock signal (CPUCLK) to
the 68020.
================================================================================
A big thankyou to Brian.
Great. Now where does that leave us? Well, in my opinion (hardware engineer)
it is non-trivial to productize something like this, though it can be done in
small quantities for less than the several hundred dollars that the 68020 is
reputed to fetch. Alos, its extremely risky to build something like this out
of a magazine article, not knnowing if it has really been done as published, or
if it represents "Mach1, Mod.0", first cut, idea stage, not de-bugged, etc.
Several companies sell them, together with the socket for a 68881 floating
point co-processor, but they're very pricey, such as CSA's approximately
$1500.00 offering (with chips). I wouldn't try a wire wrap version myself,
since I've had bad luck with wire wrap that connects to dynamic ram, due to the
possibly catastrophic (to the d-ram) effect of undershoot on the address line
that will almost certainly occur if the wire wrap lines are not properly (read
critically) damped.
How about a 68010 in the 68000 socket with a 68881 in a Starboard
multi-function module? Not even close to the performance of a 68881 running as
a coprocessor on the '020's coprocessor interface. You see, the math chip can
operate as a co-processor or a peripheral processor. So if you don't have the
co-processor interface and just hang it on the local bus, you are limited by
the bus bandwidth; and don't forget to consider the width of the data path (16
vs. 32) if you care to calculate the difference. Also, since the co-processor
interface is asynchronous, you can run the 68020 at the system clok speed
(or double?) and run the 68881 as fast as it will go, providing the clock
yourself. It will tell the 68020 when its done with the calculation. And
if that isn't enough, the 68020 can handle up to eight coprocessors!
Now (if anyone read this far) here's my problem. I have a generic
(non Amiga specific) 68020/68881 adapter board, and a set of un-marked, perhaps
un-tested chips that a friend from Motorola gave me. The glue logic is in a
couple of PALs (programmable logic). It wouldn't physically fit in the Amiga
case, so I kludged it in, the result of which is that there are about four
64-pin dip sockets between the adapter and the Amiga's socket, and half of
those 64 pins have about an inch of 30 guage wire wrap wire ( Oh No!) between
the adapter and the top socket. The Amiga boots, workbench and all, responds
to CLI commands, but crashes immediately upon a window re-size. Any ideas? I'm
running a 68010 until I figure out the adapter problem, and have no apparent
problem with the '010.
I also have the 68000, 68020, and 68881 manuals from Motorola if
annyone has any questions.
I can also be reached via mail as NAC::VISSER.
John
P.S How about a public-domain hardware project?
|
| re: adapter crash problem in .3-.6.
The June issue of Byte has a review of the CSA 68020 Turbo Tower.
In the review, the author notes that he had problems with the Amiga
crashing, and installed the CSA-recommended fix. CSA recommends
adding 3 ground jumpers to the Kickstart RAM daughterboard, improving
the grounding there.
Another possibility, more difficult to correct, is 68020 timing. Chip
RAM is shared between the CPU and graphic chipset so that for every
4-cycle processor read or write cycle, the chipset gets the first two
and the 68000 gets the last two. Since the 68000 needs at least 4
clock cycles for memory access, DTACK may be asserted well before it
needs to be. However, the 68020 needs only 3 clock cycles for memory
access. So, if DTACK is asserted too soon in the CPU half of the
memory cycle, timing can get very screwed up. Amiga hardware may
assume 68000 timing.
The unmarked PALs, etc., from Motorola are probably from an application
note that never got released. That note and the EDN article assume
asynchronous memory access, not Amiga-style synchronous shared chip
RAM.
Hmmm, what if you delay DTACK by 1/2 or one clock cycle?
|