An MC68020/68881 Coprocessor Card for the Apple II

In late 1985 I designed a MC68020/68881 coprocessor card for the Apple
II, based on an earlier 68008 card designed by Richard Ottosen.
Richard and I built the card.

The MC68020 and MC68881 are run from a common clock, which is jumper
selectable from either an on-board oscillator or the Apple II 7M clock.

The card has a 2764 boot EPROM, and 32 Kbyte of SRAM organized as
8K*32.

Communication with the Apple II is by means of four eight-bit parallel
I/O ports, two in each direction, and by one interrupt "doorbell" in each
direction. Typically one port in each direction is used for data, and
the other for status and/or handshaking.

On system reset, the MC68020 CPU is held in reset until the Apple II
releases it by writing to an I/O location.

We used two PAL16L8 chips (U2 and U12) for the address and byte strobe
decode, bus error, and interrupt auto-vector.

PAL equations:

Construction:

We didn't have wire-wrap sockets for the PGAs, so Richard constructed
custom ones by removing the pins from machined-pin DIP wire-wrap
sockets, and inserting them into suitably sized (13x13, 10x10) pieces of
perf board with the holes drilled out to a slightly larger diameter.
Most of the remaining circuitry was wired using 3M Scotchflex
insulation-displacement prototyping, which is much faster to wire than
wire-wrap, but not as mechanically robust.

PAL Programming:

This was the first time either Richard or I had used PALs. Even though
the concept seemed fairly simple, we weren't 100% confident that we'd
get it right the first time. We purchased five parts, in order to have
three spares. We borrowed a Structured Design SD10 programmer. This
was a self-contained box that had PALASM built-in, and a wafer-tape
drive for storing your source code and/or JEDEC files. All you need
with the SD10 is a dumb terminal. In practice, though, we used the
Apple II as the terminal, and kept our source files on disk.

Debugging the hardware:

I checked and rechecked the wiring. When we plugged it into the Apple,
there was a problem with lots of noise on the +5V supply, and the
card didn't run the boot code. In short order Richard and I traced this
to a fault on the R/W* line. Once this was fixed, the hardware worked.
And the PALs did in fact work the first time.

Software:

A simple monitor program was put in the EPROM, which provided a means
for the Apple II to load code into the card.

Hardware design notes from 19 years later:

With the benefit of hindsight, some issues with the design are apparent:

As designed, the current drawn from the Apple II +5V supply will be
around 1000 mA based on the components' typical Icc specifications, up
to around 1500 mA based on the maximum Icc specifications. The Apple II
Reference Manual states that 500 mA of +5V is available to be shared
by ALL of the peripheral cards. Obviously this card should not be used
in a heavily loaded Apple II family machine.

Had we used 74HCT logic instead of 74LS where possible, and
lower-power PALs or GALs, and other minor changes to the component
selection, we could have reduced the current draw to around 623 mA
typical, 756 mA maximum.

The 74LS374 latches present two LS loads on each data line on the system
bus, but the Apple II reference manual states that each peripheral card
can present a single LS load on each data line. Arguably a separate
data bus buffer (e.g., 74LS245) should have also been used, or 74HCT374
latches could have been used.

To save board space, the four 74LS374 latches could have
been replaced by two 74LS652 registered bus transceivers (uncommon),
or two 74HCT652 (even more uncommon) to meet the Apple II data bus
specification.

Epilogue:

Unfortunately the card was disassembled for parts in 1987. I should
have at least taken a photo of it. Sigh.

Some thought was given to a "mark two" card, which would have had DRAM
and direct access to the Apple II memory (handy for graphics). However,
the design was not completed.