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

[William Astle]

Wow, you've been busy.

I feel I should prefix this with a comment that I am not an expert at 
electronics at all. I know enough to know that I know nothing. Take this 
as idle musing.

For the memory board, you might consider having two modes. One which is 
"compatible" with the classic GIME using the same 6/8 bit registers and 
one which allows direct 16 bit writes to various registers. I'm not sure 
how that might be done but maybe it can be faked with some trickery on 
the bus. By that, I mean possibly tricking the hardware so that a 16 bit 
write at FFA0 only affects FFA0 but still manages to write all 16 bits? 
I think it's possible with some trickery as long as the GIME's decode of 
FFAx can be overridden by other logic. One would simply need to detect a 
write to FFA0/1, FFA1/2, ... FFAF/B0 on subsequent clock cycles and 
steal the write so that it doesn't mess up the other stuff. That's 
assuming I have the 6809's behaviour on a 16 bit write/read correct and 
that it does so in adjacent CPU cycles.

Of course, it may not be possible to do what I'm thinking but wouldn't 
it be cool if it was? Default to 2MB compatible mode but have a process 
that switches to "16 bit" mode? Of course, this might require that the 
operating system swap the byte values so as not to confuse the GIME but 
I would think that a small price to pay. :)

Come to think of it, that might be a useful trick to create 16 bit I/O 
ports on expansion boards in general on the CART port as long as the 16 
bit port is not mapped to the last address a particular device uses. 
(Otherwise there would potential conflicts between devices that are not 
cooperating.)

Now wouldn't that be bizarre? Faking out the system to write 16 bits at 
a single address without affecting the next address? For any "port" that 
is always accessed as 16 bits, I can see it might be useful given the 
scarecity of addresses in FFxx.

On 10-07-05 05:05 PM, Little John (GIMEchip.com) wrote:
> 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 
gu
>   ys 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 u
se
>   d 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 perse
ver
>   e.
>
> Thanks Guys/Ladies - John
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco