[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