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

Mon Jul 5 21:13:16 EDT 2010

William,
That's a great idea. What I had intended was to use the $FF8x area. The MSB 
of the MMU registers would be located at $FF8x while the LSB's would be in 
the normal $FFAx range. On power up (but not reset), the $FF8x would 
automatically be reset to 00's to maintain compatibility with the normal 
DISTO method of 2-Meg's at power up. 16-bits would give us a total of 65,536 
8K MMU blocks, totalling 536,870,912 bytes of memory for use by the CPU. 
That's 512Megs of memory that is completely accessible to the CPU. Now, the 
video circuit does not have a clue as to what to do with anything over 
512K-bytes. Tony solved this by creating a video bank register at $FF9B. He 
used the lower two bits to select 1 of 4 512K Banks during a video cycle. 
So, during a CPU cycle - the DAT memory is muxed into Z9, but during a Video 
Cycle, the two Video Bank Bits are muxed into Z9. Tony is a GENIUS. So, what 
I would do would be to use all 8 bits of Tony's video bank register which 
would allow 256 different 512K banks any one of which could house the video. 
I believe this is completely attainable. Also, all 512Megs doesn't have to 
be RAM, you could stick in some FLASH/EEPROM or what have you. This will 
probably be the coolest of all of my projects and now that I have a 
recommendation of a cool CPLD to use, I can make the design even simpler. My 
dad gave me his vintage stuff to keep me busy while I'm unable to work. I 
figure all of you guys have supported me by buying my stuff over the last 
three years, so I am releasing everything that I design as fully open 
projects for all to use as they see fit. Thanks to you all :-)
-John
----- Original Message ----- 
From: "William Astle" <lost at l-w.ca>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Monday, July 05, 2010 7:29 PM
Subject: Re: [Coco] Can Someone Recommend A Small CPLD for the 8-Slot MPI?


> 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
>
>
> --
> 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/2984 - Release Date: 07/05/10 
13:36:00