[Coco] What would a CoCo successor have to have as a minimum?
sales at gimechip.com
Sat Nov 20 22:59:19 EST 2010
Although I am working on a 512K SIMM for the CoCo 2 (to be compatible with
the JR BANKER BOARD), the current design is for the CoCo 3/GIME. The refresh
is accomplished by feeding E,Q,HSYNC,VSYNC into the CPLD- during any HSYNC
or VSYNC period, the SIMMs are forced into an internal refresh using their
own counters. This would easily fit into an XC9572 - I've actually stuffed
the refresh circuit into a lowly 16V8 plus an added 74HC74. On the 72 pin
simms, I'm not using them as 32-bits, but rather as four 8-bit banks,
determined by cas0-cas3. Since a 72-pinner has only a single /WE, pairs are
required. I'll collect all of this together tomorrow and get it to you if
you'd like to experiment. A larger CPLD might be required to fully implement
the 512M design fully - I initially did the design using SPLD's & HCTTL.
Obviously - a CPLD is the only real way to go because it will eliminate the
need for the dual port sram/register file and save a ton of chips. Plus, any
setup and hold time delays that may be needed can be simply coded into the
Back to the 512K CoCo 2 upgrade - these traditionally require a 74LS785 SAM
and 41256 chips, but if I can apply the same refresh scheme as I'm using
with the CoCo 3, the old 74LS783 SAM can be left in and 256K (any chip
count) SIMMs can be used. I don't have a lot of time to work with the CoCo 2
upgrade, but I'll start on it after I've got everything together for this
CoCo 3 upgrade.
I'll get all of my notes together and email them to you tomorrow if you'd
like. It would be a lot easier to get it going if we all work on it. Heck,
we might even find someone willing to produce them...
----- Original Message -----
From: "John Kent" <jekent at optusnet.com.au>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Saturday, November 20, 2010 9:41 PM
Subject: Re: [Coco] What would a CoCo successor have to have as a minimum?
> Hi John.
> Would the CPLD include the memory controller logic, or would you rely on
> the SAM in the CoCo to do the refresh ?
> I would have thought that the wider column would mean that it would need
> it's own refresh counter.
> There is also all sorts of initialization sequences to set up burst length
> and access timing and so on.
> I have wanted to play with Xilinx CPLDs. There operate of 5V and you can
> get them in PLCC packages. (It's easier for me to solder a plate through
> PLCC socket as opposed to a QFP). I would imagine though that to implement
> the memory controller you'd need a fairly large CPLD, and you'd have to
> multiplex the 32 bit data bus onto a 8 bit CoCo bus. You'd also probably
> need some way of buffering the SDRAM data so that it could be randomly
> accessed by the CoCo. i.e. You'd have to hold the processor if you wrote
> to SDRAM during a refresh cycle.
> On 21/11/2010 2:14 PM, Little John wrote:
>> There are two sets of task registers, 8 bytes each with the TR bit
>> determining which of the two is active :-)
>> I can provide you with all of the design details. I doubt that I would
>> ever get around to building it - but I may one day - it would require way
>> too many 30 pin simms, so I'm having to design with 72 pin simms which
>> could theoretically max it out with 4 modules of 128MB. I was going to
>> stick the whole thing in a Xilinx CPLD...
>> -John also ;)
> Coco mailing list
> Coco at maltedmedia.com
More information about the Coco