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

Sun Nov 21 13:00:59 EST 2010

If I may make a suggestion here when it comes to backward CoCo 1-2 
compatibility why not take a hint from what Apple has done and create an 
Emulator within the FPGA design so that if and when users want to dust off 
their good old CoCo 1 & 2 games they can do seamlessly, hey just a 
suggestion. ;)
----- Original Message ----- 
From: "Little John" <sales at gimechip.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Sunday, November 21, 2010 3:06 AM
Subject: Re: [Coco] What would a CoCo successor have to have as a minimum?


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