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

[Little John]

Okay John, I'll get the notes together. I've seen a lot of your work 
online - I guess you could say I'm a fan. Actually - my son designed almost 
all of the stuff I'm working with - I've just been working to debug it - one 
of the stipulations that my son imposed upon me is that anything that he 
designs must be completely "open" and available to the coco community and he 
asked that anything I contribute be the same, so I respect his wishes. He 
hasn't posted here in awhile - he's been home a few weeks now and hopefully 
he'll get back into all this soon (i need a break :-)) By the way guys, if 
you need to talk to him, or if you guys were working with him on things, 
please email him here. Let's get him back in the groove - when he gets to 
working on this stuff, he cranks out some amazing stuff.

As for the SDRAMS - I think the controller you are referring to actually is 
intended to control SDRAM of the types such as PC100 or better. They are 
accessed differently than the 30 pin fpm and 72 pin edo and fpm modules, so 
it would likely be extremely difficult to get them going in a CoCo 
environment. Using the older FPM and EDO isn't quite as difficult.

I was hoping cloud9 would be releasing a 2-meg memory upgrade - it's 
something my son has been working on for a long time and we've finally 
worked it out. I'd love to make some of them, but I'd rather buy from an 
established vendor a ready made unit :) (I'm lazy)

I'll get back with you in awhile - I've been over at my nephews watching TV 
with the Lil' guy while his dad is at work.

Remember guys, anyone reading this that was working with my son - send some 
emails - I'll put them in a folder so I can get them to his attention - 
let's get him back to work on the coco.
John's DAD - 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 10:55 PM
Subject: Re: [Coco] What would a CoCo successor have to have as a minimum?


> 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
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco