[Coco] What would a CoCo successor have to have as a minimum?

[Little John]

John,
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 
VHDL.

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...

-JohnT-

----- 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.
>
> John.
>
> 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 ;)
>
> -- 
> http://www.johnkent.com.au
> http://members.optusnet.com.au/jekent
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco