[Coco] Can Someone Recommend A Small CPLD for the 8-Slot MPI?

[Little John (GIMEchip.com)]

I am looking at a complete redesign of the 8-Slot MPI using a small CPLD. This would allow a more cost effective version to be designed and once I get a good board layout, any changes would be done in code. It doesn't have to be a 5V CPLD - since I am powering the device with an ATX power supply, a 3.3V CPLD with 5V Tolerant I/O would be perfect. The use of a CPLD would allow me to code a separate set of buffers for each slot (and the MPI design could technically be expanded to 16 slots - but that's just OVERKILL.) - this would alleviate my concerns over fan out as well. I would like to stick with XILINX since they provide free design tools, but if other companies offer free design tools, I'd be willing to use them too - right now I'm a borderline "broke" dude - this economy is the pits (but I'm not allowed to work just yet anyway - hopefully soon Mr. Dr. will sign off on my going back to work. - once that happens my design time will evaporate, so toss me all the ideas you guys can while I have the time to complete them.)

Thanks for everything my friends. I have got to finish the PIA Pak that one of you requested - I forget who it was but I'll get it done after I upload the PLD code for the current work in progress MPI. Speaking of the PIA Pak, I am designing it so the PIA's can be mapped at either $FF1x/$FF3x (only useful with a CoCo 3, but won't normally function in an MPI - I have developed a PAL for the 26-3024 MPI that opens up FF1x/3x for use on a CoCo 3), and can also be mapped to the $FF4x area. I listen to all of your requests and do my best to provide the designs that you ask for. You guys give me a reason to keep on keeping on...

I have worked out a 512K SIMM upgrade that can use any 30-Pin SIMM's, not just the 8/9 chip kind. I still need to test it. It should also work with 72-Pin SIMM's though it will waste most of their capacity. What I have done (and a lot of this is based on questions that I asked Mr. Paul Barton - his replies helped out a lot) is take in CAS*,RAS*,HSYNC*,VSYNC* and E into a small PLD. Using these signals, it is possible to derive signals to determine when the CoCo is accessing the memory for Video via the GIME, accessing the memory for CPU via the GIME, or when No Memory Access is taking place or a refresh is being done. This is so much simpler than the way DISTO did it (Tony used a 4-bit counter in Sync with the E clock to synthesize these signals, but Paul helped me (read that: told me) how to derive these signals quite naturally from the sync's, e and ras/cas.) I have allowed a DAT6 & DAT7 input into the PLD and have included multiplexing of that into z9, so this could be used as a 2-meg memory board if you built up Tony's DAT board. What the PLD does (it's just a plain old cheap 16V8) is: During any NON-CPU or NON-VIDEO cycle (and only during HSYNC or VSYNC times) - swap's CAS for RAS at the SIMMS and truncates CAS so that it terminates simultaneously with RAS forcing a CBRefresh using the SIMM's internal counters. During CPU or VIDEO cycles, everything works as normal. In addition to forcing refresh during an HSYNC (the time the GIME normally uses to do refresh), the PLD also uses VSYNC time for refresh. I hope to get this done and out there soon for all you wonderful CoCoists. I've decided to go ahead and do the 512Meg upgrade too thanks to Paul teaching all about refresh :-) I'll extend the MMU bits to 16-bits but this will be done in such a way as to allow Nitros9 to function as if it were still a 2-Meg CoCo. Give me more suggestions - keep me busy working guys - some of my designs will fail, some will work, but I shall endeavor to persevere.

Thanks Guys/Ladies - John