[Coco] ROM Dump

[RETRO Innovations]

On 4/8/2021 8:32 PM, Melanie and John Mark Mobley wrote:
> Bruce,
>
> The CoCo was not modified to use Static RAM.
> Static RAM works the same as dynamic RAM.
> Except static RAM will ignore refresh logic.

:-)

<pedantic mode on, so feel free to ignore, technical details ahead>

Directionally, the above is correct, but early DRAMs used what was 
called row refresh logic.  Givne teh Row/Column nature of DRAM, almost 
all early DRAMs were organized as X * Y matrices of RAMs, with either a 
X1 bit wide DRAM cell or X4 half byte(nybble) wide DRAM cell at each 
matrix position.  The rule for DRAM was that each row in the DRAM had to 
be "refreshed" or charged up, once every so many milliseconds. The neat 
feature was that simply accessing a DRAM memory location within that row 
would refresh all the cells in that row. So, in early DRAMs, the easiest 
way to keep the DRAM running was simply to have a counter and "read" a 
byte from each row every so often, such that reading all the rows once 
took less than the number of milliseconds required to keep the DRAM charged.

So, in those situations, the DRAM doesn't distinguish from a normal read 
cycle and a dummy read cycle designed to act as a refresh.  Both are 
valid memory reads.

Later, DRAM ICs incorporated an internal counter on the IC, and you 
could use the row address trobe (RAS) and/or column address strobe (CAS) 
lines in various combinations to signal the DRAM IC to essentially 
"read" a row of the memory internally, using the counter on the IC. The 
counter was a simple addition to the IC die and the feature offered some 
speed and power savings.

Depending on how the GIME implements the memory refresh (I put it onthe 
logic analyzer years ago, but I honestly forget how it handles 
refreshes), the static RAM could see the refresh cycle as a read cycle, 
so it would not actually ignore it, it will respond to it, but the GIME 
doesn't care about the data the SRAM delivers.

As Dave notes in another response, CC3 SRAM options work by converting 
the row/column address of a DRAM into a single value for the SRAM to 
use.  Since the row is sent first, the typicaly solution is to stash the 
row value when the RAS line goes low, and then feed that into part of 
the SRAM, while sending the raw DRAM address line data into the 
remaining address lines of the SRAM.

* Thus, if the GIME does a "dummy read" refresh, the SRAM will handle 
that as a read.

* If a RAS-only refresh (one of the newer refresh options) is used, then 
John Mark's original note is probably accurate.  I don't know the 
specifics of the various memory options being sold except for the kit 
version I sell, but the address is only fully valid once the CAS line 
goes low, so I expect commercial offerings use the CAS line as the "chip 
select" line on the SRAM.  Since a RAS-only refresh doesn't set the CAS 
line low, the entire cycle would be ignored.

* If a "CAS before RAS" (CBR) refresh sequence is used (this works 
because a normal read would see the RAS line go low first), the SRAM 
will most likely do 2 (two!) reads within  the cycle. The CAS line will 
go low first, which will most likely enable the SRAM for a valid read 
(chip select), but we don't have a full valid memory address (we only 
have what is on the DRAM address lines at that point, and they are 
directly routed to a part of the SRAM address lines.  The rest of the 
lines most likely still how the row value *FROM the LAST memory location 
read* :-). But, then a while later the RAS line will go low, and a new 
value will be latched into the "row storage" noted above and by Dave's 
response.  So, if the last memory location read from R1:C1 and then a 
CBR is performed with DRAM address data=2. the read sequence will be 
(read from R1:C2 for a bit, and then read from R2:C2).  It's a bit more 
work for the SRAM for no benefit, but: SRAMs are much lower power and 
the reads don't hurt anybody, so all ends well.

And now you know more than you ever wanted to know about DRAMs and SRAMs.

</pedantic>

Jim