Multipak upgrade

What does an MPI do, and why does it have to be upgraded? 

Back in the day, small computer systems addressed everything as RAM. Great theory, but silicon was expensive in the eighties and a random subset of 16 address lines can be many logic gates added to the cost of every expansion card. To support cheap external hardware, computers of the day would provide 'slot select' signals. The card could use that, plus a few low order address lines for it's internal registers, and job done.

Apple had 4 slots, which covered a reasonable amount of expansion. The CoCo only had one, unless you add an external device like the MPI.

There are two output signals denoting a preselected address range.

CTS $C000 - $FDFF read only ROM software
SCS $FF40 – $FF5F read/write hardware

The CoCo also accepts two related inputs from ‘the’ external device.

CART A valid external ROM is present, run it.
SLEN Disable CoCo’s internal address decoding.


For a single device, simply connect SCS to the chip select for your hardware, and/or CTS to the chip select for your ROM chip. To auto run your ROM on startup, tie CART low. This lashup will ‘ghost’, in other words that low order address pattern will be repeated throughout the select range.

This is fine for one device, but what happens when two 'standard' expansion cards are plugged in? They stomp on each other, of course. And that is where  SLEN comes in. An external device can ask the SAM/GIME to kindly not put out the CTS and SCS signals. The full address is still present on A0-A15, but no shortcuts. The MPI asserts this signal to assume control of the SCS and CTS shortcuts to, and the CART response from, each slot. It does this job just fine on any model CoCo, nothing to see here.

But the ghosting problem hasn't gone away, it's just been relocated. First, we need to identify the CTS range $C000-$FDFF, which looks like this in binary:

  C000 11000000 xxxxxxxx
FDFF 11111101 xxxxxxxx

where all possible values in the xx positions will fall inside the range and can be ignored. For decoding work we only have to consider a range of 8 bit numbers.

The end of SCS is more expensive, 12 significant bits to puzzle out FF40-FF5F. Why not cut one more bit off for expansion? On a CoCo One or Two, this area is not used... and so, the MPI stops decoding at A5 so the SCS or read/write range is:

  FF40 11111111 010xxxxx Start of SCS
FF9F 11111111 100xxxxx End of MPI range
FF7F 11111111 01101111 MPI slot select

This a problem for CoCo3, which wants the FF9x range for the GIME. The original 'big' MPI were actively hostile, letting writes to $FF7x echo to the related address $FF9x. Luckily, the ‘big’ MPI have an easy fix, replace the socketed PAL chip.

Newer MPI are more subtle, they don’t echo writes themselves but do leave both active. This could have been a BFD, ASICs are not as easy to replace as PALs, even if there was a socket. But somebody spotted a workaround.

Address table bit 7 is only set when CTS is active, or we are in the no-no range &FF9x. So all we need to do is hijack the MPI’s internal select signal ‘ENBUS’ and disable it when CTS isn’t active and address bit 7 is high (one). As luck would have it, this hijacking can be done outside the ASIC chip with a simple trace cut.

This must be done inside the wonder world of active low signals. Logic gates compare the ones. Active low signals are not ones and cannot simply be OR’ed together. Instead of asking our original question ‘is CTS set or SLEN set or bit A7 = 0? you have to ask ‘is CTS not set and SLEN not set and bit A7 = not 0 ?

And then, a NAND gate flips the output to again be active low. So once a second input stage determines ENBUS is not set we can finally compare if ENBUS isn’t not set, CTS is not not active or SLEN is not not active or address A7 is not not zero. Resulting in an output ENBUS* signal with $FF9x chopped off that we can supply to the rest of the MPI on other side of the trace cut.