[Coco] Replacing Dynamic RAM with Static RAM

sales at gimechip.com sales at gimechip.com
Fri Jun 11 22:41:06 EDT 2010


My name is John. I will be putting everything I've done on CoCo 3.com and 
you can use anything you find there from me as you see fit. I love that 
site - I think I like this list too :-)

The 512K CoCo 3 SRAM upgrade does need to be tested. The Basic circuits used 
in the design have all been tested (such as the demultiplexing), but I 
haven't tested it as a 512K CoCo3 upgrade. Once we get that working for 
certain, then we can work on extending it to 2-Megs - the 1Meg is probably a 
moot point since the chips you have are 2Megs, we should just go straight to 
that. There is another guy on coco3.com working with this too - if we all 
get together on this we could probably bring it alive sooner. One thing that 
I would like to make certain of is that the two added MMU bits are both 
R/W - in Tony's 2-Meg, they were read only. This is fine as far as 
OS-9/NitrOS goes since the OS keeps up with the data written into the 
registers. Still, since the 6-bits of the GIME can be written and read, it 
would be nice if the added 2 bits could be read as well. The CoCo 3 service 
manual states that the MMU registers are write only - this is false - you 
just have to mask off the upper 2 bits to get the actual data that was 
stored there.

I have also considered a 512M upgrade. I know it's ridiculous, but it's 
possible. If we use Tony's Video Bank Register and use all 8-bits of said 
register for Video Banking, then the first 128Meg of memory could house the 
video (there would be 256 banks of 512K, any of which could be selected to 
house the video). The CPU on the other hand could access the entire 512Megs 
via the MMU paging. We would have to extend the MMU registers to 16-bits, 
which would provide 65536 blocks of 8K RAM. In order to accomplish this, we 
would have to use $FF80-$FF8F as the upper 8-bits of both sets (tasks) of 
the MMU registers. So $FF80 and $FFA0 would contain the 16-bit value for 
Task 0, MMU Register 0, and so on. Since $FF8x was reserved for future use 
it would be perfect for this.
Of course, 512Megs is a lot of memory and so static RAM would probably not 
be feasible for this type of upgrade, so we'd have to work out the refresh 
requirements. My reasoning for doing it this way - 16-bit page registers, is 
in the hope that NitrOS-9 would be able to use the entire 512 megs.

Boisy - would it be possible for OS-9 Level 2 or NitrOS-9 to be modified to 
use 16-bit paging? If not, then this project probably wouldn't have any 
practical uses other than RAMdisks, or storing several video pages for rapid 
animation. I was just wondering.

I will put together a complete synopsis of all of the memory expansion work 
that I've done and post it to CoCo3.com and we can go from there. Note that 
Paul Bartons pages have been the inspiration for all of this. You guys 
should go check out Paul's LED Cubes - the video's are pretty cool - his 
page is: http://www.onlyonsaturdaynight.com/



-John

----- Original Message ----- 
From: "Stephen Adolph" <twospruces at gmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Friday, June 11, 2010 7:37 PM
Subject: Re: [Coco] Replacing Dynamic RAM with Static RAM


J&R,
Whats your name btw.

I have circuit boards for another project that should have all the
connectivity and stuff needed to implement this.  I just don't know
what the logic design is.  So, we could avoid PCB costs too, at least
for low volumes.

I'm also quite good at the soldering part.

Steve


On Fri, Jun 11, 2010 at 4:40 PM,  <sales at gimechip.com> wrote:
> Absolutely - putting the logic into a CPLD would be ideal. The ideal latch
> would be a 9-bit non-transparent if you decide to put the design into a 
> CPLD
> - you can use the schematic entry and let the development suite generate 
> the
> HDL's. I'll send you all of the info when I get it together, if you want -
> just let me know - I love working out this stuff. It's like a puzzle, only
> way better :-)
> J&R
> ----- Original Message ----- From: "Stephen Adolph" <twospruces at gmail.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Friday, June 11, 2010 2:56 PM
> Subject: Re: [Coco] Replacing Dynamic RAM with Static RAM
>
>
>> I have a large quantity of 1M x 16 3.3 V SRAM chips, and a large
>> quantity of CPLDs.
>>
>> These parts are perfect for such a card.
>>
>>
>>
>> On Fri, Jun 11, 2010 at 3:06 PM, <sales at gimechip.com> wrote:
>>>
>>> I just noticed the mention of using a single 2-Meg SRAM. That's what 
>>> I've
>>> been working on, but the SRAM is 1024x16 for a total of 2-Megs by eight.
>>> The
>>> GIME has a 16-bit databus (sort of). Even bytes are in one bank and odd
>>> bytes in the other, thus a 16-bit SRAM or two 8-bit SRAMs are ideal. It
>>> can
>>> be done with an 8-bit wide SRAM as well, I suppose, but I haven't tried
>>> that
>>> yet.
>>>
>>> I am using a 16x4-bit RAM array with associated multiplexing circuits to
>>> extend the MMU registers by 8-bits.
>>>
>>> Since I'm using Static RAM, no modified refresh is required, plus if the
>>> SRAM is battery backed, the various RAMdisk software can be non-volatile
>>> (although some of the RAMdisks initialize the disk automatically - that
>>> behavior would have to be patched out)
>>>
>>> The video can only exist within a 512K block - this is a GIME 
>>> limitation.
>>> Using Tony's method, a register holds the Video Bank data. During a 
>>> video
>>> cycle, the video bank data is presented to the RAM to select 1 of 4 of
>>> the
>>> 512K banks for video.
>>>
>>> The CPU, however, can access the entire 2-Megs via the normal paging
>>> method.
>>> During a CPU cycle the DAT register addresses are presented to the 
>>> Static
>>> RAM.
>>>
>>> There's a little bit more to it than that (for example, the dual WE*
>>> signals
>>> must be accounted for - I've done this by multiplexing them and using A0
>>> to
>>> select which one passes to the SRAM for R/W* control - A0=0=even bank,
>>> A0=1=odd bank). This should be completed soon. I'll upload everything to
>>> coco3.com and maltemedia for any who want to make use of it.
>>> J&R
>>>
>>> ----- Original Message ----- From: <sales at gimechip.com>
>>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>>> Sent: Friday, June 11, 2010 1:50 PM
>>> Subject: Re: [Coco] Replacing Dynamic RAM with Static RAM
>>>
>>>
>>>> Yes, that's what these were for, but I also uploaded a file that uses a
>>>> 256Kx16 SRAM for the CoCo3 for 512K. It needs a bit of work. It's here:
>>>> http://www.coco3.com/community/2010/06/512k-simm-and-sram-files
>>>>
>>>>
>>>> ----- Original Message ----- From: "Stephen Adolph"
>>>> <twospruces at gmail.com>
>>>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>>>> Sent: Friday, June 11, 2010 1:21 PM
>>>> Subject: Re: [Coco] Replacing Dynamic RAM with Static RAM
>>>>
>>>>
>>>> Interesting.
>>>> I've got a background activity thinking about how to use a single 2MB
>>>> SRAM
>>>> chip.
>>>> Seems that this is a way to replace each individual DRAM with an SRAM.
>>>>
>>>> Similar, yet different. hmm more thinking.
>>>> Steve A
>>>>
>>>>>> On 6/11/2010 8:57 AM, sales at gimechip.com wrote:
>>>>>>>
>>>>>>> Over the past year, I've had some success at replacing DRAM with
>>>>>>> SRAM.
>>>>>>> I
>>>>>>> have posted some of the schematics and designs to CoCo3.com in these
>>>>>>> threads:
>>>>>>>
>>>>>>> http://www.coco3.com/community/2010/05/512k-upgrade-question
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://www.coco3.com/community/2010/06/4164-dram-sram-replacement-1-by-jr-of-gimechip-com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://www.coco3.com/community/2010/06/4164-dram-%E2%80%93-sram-replacement-2-by-jr-of-gimechip-com-c19-march-2010
>>>>>>>
>>>>>>> It is relatively simple to demultiplex the multiplexed address lines
>>>>>>> and
>>>>>>> to replace DRAM with SRAM. The above links should provide a great
>>>>>>> deal
>>>>>>> of
>>>>>>> information on how I've gotten it to work.
>>>>>>>
>>>>>>> As soon as I get the rest of my documents together on the 512K, 1M&
>>>>>>> 2M
>>>>>>> CoCo 3 Static RAM upgrades, I'll get those posted as well. -J&R
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG - www.avg.com
>>>>> Version: 9.0.829 / Virus Database: 271.1.1/2931 - Release Date:
>>>>> 06/11/10
>>>>> 01:35:00
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 9.0.829 / Virus Database: 271.1.1/2931 - Release Date: 
>>>> 06/11/10
>>>> 01:35:00
>>>>
>>>>
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 9.0.829 / Virus Database: 271.1.1/2931 - Release Date: 06/11/10
>>> 01:35:00
>>>
>>>
>>> --
>>> 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
>
>
> --------------------------------------------------------------------------------
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.829 / Virus Database: 271.1.1/2931 - Release Date: 06/11/10
> 01:35:00
>
>
> --
> 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


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.829 / Virus Database: 271.1.1/2932 - Release Date: 06/11/10 
13:35:00




More information about the Coco mailing list