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

John Kent jekent at optusnet.com.au
Sat Nov 20 23:55:50 EST 2010


Hi John T,

I designed a 1MByte RAM board for the Amiga 1000 back in the 1980s. It 
used 41256 RAM chips I think ... or something similar. I used a TI 
THCT4502A memory controller as I recall, and I used SmART Work to design 
the board which might have even been a DOS program which is how long ago 
it was. It had a hard disk interface port for a WD1002 board and a 
Motorola MC146818 (?) calendar clock chip with battery back up.

If you time the refresh with the video synch pulse, then yes,  you don't 
have to worry about refresh timers, which simplifies the design a 
little, and as you say the refresh counters for the SDRAMs are internal 
to the SDRAM chips.  I was thinking more in terms of the complexity of 
the SDRAM controller provided by XESS Corp for their XSA-3S1000 FPGA 
board. There was a reasonably complex state machine to control the 
accesses and refresh timing. There was also a start up initialization 
mode that configured the SDRAM timing, via a control word. I'm not sure 
if the SIMM memory needs that or not. There was a fairly complex start 
up procedure to configure them.

Send me your notes and I'll take a look. I don't actually have a CoCo, 
other than Gary's FPGA implementations, so it might be had for me to 
verify any of the designs. I did have a friend who had a Coco but I've 
lost touch with him and I don't know what model it was.

John K.

OK on using just 8 bits of the bus .... That sounds reasonable.

On 21/11/2010 2:59 PM, Little John wrote:
> 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-
>

-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent




More information about the Coco mailing list