[Coco] MPI replacements?

Little John (GIMEchip.com) sales at gimechip.com
Fri Jul 9 16:42:36 EDT 2010


I have used EPROMs for a variety of logic functions. I once used one to 
remap a keyboard matrix on one of my older vintage computing projects. I 
have a giant supply of GALs though - I bought a bunch in bulk - 16V8's and 
22V10's. I'm using a 22V10 in the 8-Slot MPI.

I can give you all of the specifics of Tandy's MPI:
It's just a set of buffers on the Address Lines and some of the control 
lines. Reset is buffered one way, so a Cartridge can't reset the coco - I'd 
like to devise a "bi-directional' buffer on the reset line...
A bi-directional buffer on the data bus which is enabled on: CTS* (a read 
only select for the external cartridge ROM area $C000 up), SLENB* (a signal 
that disables the CoCo's internal 74LS138 - if a cartridge asserts this 
signal, it can take over an area of the coco memory normally used by other 
internal peripherals), and $FF40-$FF7F (the last official area assigned for 
CoCo I/O expansion).

There is a latch and buffer forming an 8-bit readback latch (register) at 
$FF7F. Writing to this area selects the slot that has CTS*/CART* and SCS* 
signal.
Basically, the upper 4 bits point to the slot for CTS*/CART* and the lower 
4-bits point to cart that has SCS*. As you can see, the design actually 
allows for a total of 16 slots, but this is NOT practical - the buffers 
would soon be overloaded exceeding their fan-out capacity - honestly, I 
think 8-slots is pushing it.
A 1-of-4 decoder has CTS* as it's enable and the MSB (only the first two 
bits in Tandy's MPI) of the slot select register as the A and B inputs. This 
Routes CTS* to one of the 4 slots. Similarly, the same is done for SCS*, but 
select is made by the LSB. Finally, a 4 to 1 MUX takes in the CART* 
interrupt and routes the one from the slot selected by the MSB (CTS*) of 
slot select register back to the CoCo. As Gene Heskett pointed out, many 
people have bypassed the CART* selection by wiring all the CART* interrupts 
together (WIRE-ORed) and back to the CoCo - this is almost a requirement for 
OS-9 to not lose characters from, say, an RS-232 Pak. My 8-slot design 
allows you to selectively bypass the interrupt on a per-slot basis. There is 
also the slot select switch - on power up or reset, the MPI points both SCS* 
and CTS*/CART* to the slot selected by the switch. After a write to the 
$FF7F register, the switch is disabled until reset or power is cycled. 
That's about it - it's an extrememly simple design, so when I was asked to 
clone it, I was relatively certain that I could do so rather painlessly.
-John

----- Original Message ----- 
From: "Rob Rosenbrock" <rob.coco at zaphod.tzo.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Friday, July 09, 2010 3:18 PM
Subject: Re: [Coco] MPI replacements?


> Never mind... Without knowing more about the specifics, I think I jumped 
> in a bit soon.
>
> On Jul 9, 2010, at 4:15 PM, Rob Rosenbrock wrote:
>
>> Rather than a GAL or discrete logic, have you ever considered using a 
>> small ROM? I've seen one implemented utilizing it as a truth table.
>>
>> At least I think a small 1K x 8 ROM should still be available...
>>
>> On Jul 9, 2010, at 3:20 PM, Little John (GIMEchip.com) wrote:
>>
>>> James,
>>> I have had several people suggest that I redo the design using a single 
>>> PCB rather than the two. This is a good idea.
>>>
>>> I wanted to use a CPLD to put the whole thing into, but a couple of 
>>> different folks suggested that SMD 74xx series would be preferable and 
>>> I'm thinking they are right.
>>>
>>> There is a GAL in the design to determine when to enable the data 
>>> buffer, but even this could be done in discrete logic, though I will 
>>> keep the GAL because it allows me to economically add a few extra 
>>> features, such as a jumper to enable the $FF8x range if desired, as well 
>>> as enabling writes to $FF0x (so external user peripheral devices could 
>>> receive data that is written to the PIA) - this would be write only, 
>>> otherwise contention would result on reads of the PIA. The $FF1x area 
>>> can be enabled for both reads and writes (on a CoCo 1 or 2, this should 
>>> only be enabled on writes, or not at all, On a CoCo 3 this area is 
>>> available for read and write), $FF2x (same conditions as $FF0x), $FF3x 
>>> (same conditions as $FF1x) and so on - the idea is to create the most 
>>> flexible MPI replacement possible while still allowing 100% 
>>> compatibility with the Tandy MPI.
>>>
>>> I have also decided to release all of my projects as completely open and 
>>> allow others to manufacture & sell them if they so desire, Royalty free. 
>>> I started this venture to benifit the entire CoCo community, and to keep 
>>> my mind off being sick. It's win-win for me and hopefully all of you 
>>> folks as well.
>>>
>>> In the long run, I would like to design a replacement CoCo 3 motherboard 
>>> with built-in slots and an ATX form factor - a GIME would be all that 
>>> would need to be plugged in - which means a deceased coco 3 would be 
>>> needed to snag the GIME. Now, this project is more likely to never reach 
>>> completion that to be completed - it's a lot of work, but if there are 
>>> any folks who want to start a design team - I'm all in - just give me a 
>>> holler (that's southern talk Y'all) :-)
>>>
>>> I'm always spending almost all of my waking hours working on this stuff, 
>>> and when I get stuck, Dad helps (yeah - I haven't done all of this work 
>>> by myself - I've had help - it's just my determination to see this all 
>>> thru)
>>>
>>> Thanks Guys (and Ladies) - if you have ideas for designs - pitch them to 
>>> me - I'm always glad to help.
>>>
>>> -John
>>>
>>>
>>>
>>> ----- Original Message ----- From: "James Dessart" <skwirl42 at gmail.com>
>>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>>> Sent: Friday, July 09, 2010 11:19 AM
>>> Subject: Re: [Coco] MPI replacements?
>>>
>>>
>>>> On Thu, Jul 8, 2010 at 6:54 PM,  <jdaggett at gate.net> wrote:
>>>>> How small is small?
>>>>
>>>> Ideally just the board, connector for the CoCo, edge connectors for
>>>> the individual cards and a connector for an ATX power supply, to fit
>>>> into an ATX case or whatever for a repack. If anything needs switches,
>>>> movable jumpers would be fine.
>>>>
>>>> The idea is to make my CoCo system take up as little space as
>>>> possible, so I'd probably be adding an RGB converter and whatever I
>>>> can to reduce system footprint.
>>>>
>>>> -- 
>>>> James Dessart
>>>> <http://ideaoubliette.blogspot.com/>
>>>>
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 9.0.830 / Virus Database: 271.1.1/2991 - Release Date: 07/09/10 
>>> 01:36:00
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.830 / Virus Database: 271.1.1/2991 - Release Date: 07/09/10 
01:36:00




More information about the Coco mailing list