[Coco] CoCo Projects

[RETRO Innovations]

On 2/23/2016 7:43 PM, Michael Brant wrote:
> Jim, that is good to hear about the MPI. you may have discussed this but
> was there any consensus on a case for your MPI?
Yes, I owe a few folks on the list a CAD drawing of the PCB so they can 
design cases.  A fewother issues have slowed me up for the past few 
weeks, but I'll get it posted soon.
> And is it still going to
> be able to support more than 4 carts if a second board is connected?
Well, it will support 4 more carts, but on has to realize that there are 
some restrictions in how things work:

MPI only massages SCS and CTS lines (well, and cart lines coming back, 
but...).

So, for carts that fully decode their addressing or are outside the SCS 
or CTS addresses spaces, the additional ports mainly serve to create 
more potential conflicts.   Namely, the more carts you have on the bus, 
the more likely two of them will decode to the same place in $ffxx and 
thus not work together

I thought about modifying the design to gate additional bus lines to 
each slot (A0-A15, SLENB, and maybe R/W, but not Q or E since the cart 
might need a steady clock signal for something), and might still do it 
(I could emulate the original MPI by enabling the buffers on all slots 
initially, and putting all of the SLENB lines on a wired/or config).

But, I hesitate due to the potential SW problems.  Some applications are 
designed to expect a HW device to be "always" there.  For instance, 
since the Glenside IDE does not trigger off of SCS (I think it should 
have, but that ship sailed long before I showed up), IDE is available no 
matter witch slot is selected.  Thus, if the user truly "isolates" the 
slots, then the IDE HW (HDBDOS, I assume) will start failing unless the 
specific slot that contains the IDE controller is selected.

Jim