[Coco] GIME DRAM address mappings

[RETRO Innovations]

On 9/28/2017 10:10 PM, RETRO Innovations wrote:
>
> The quick answer is that bit 10 is stuck high or something, but I 
> don't see that on the logic analyzer.  And, no matter what multiple of 
> 512 I write to, the screen gets a copy within the 512 byte range of 
> the screen.  So, for example, if I wrote to 2048+148, a phantom write 
> goes to $494 (1024+148)  I have verified that if I write a 99 to 
> location 1504+512, I see the same 99 at location 1504 (low left of 
> screen memory)
>
> At first I thought the RAM was just limited to 512 bytes, but if I 
> write 99 to 1504+1024, 1504 has 99, but 1504+512 does not.
>
> And so, I continue to debug... :-(

And, now, I have found success! \o/

For reference, here is what happens:

  * Right in the middle of the high part of the E cycle (and right
    before Q goes low), one the respective *WE lines is pulled low, to
    signal to the DRAM which bank of RAM will receive a byte of data. 
    Essentially, *WE0 is low during a write to an even location, *WE1 is
    for odd addresses
  * At the same exact time, the *RAS (row address strobe) line goes low,
    latching the row address into the DRAM (the low part of the address,
    along with bit 4 of the MMU bank as the high bit)
  * ****BUT****, and this is what I was seeing but not comprehending,
    the *CAS line has not fallen, so the high partof the address is
    still showing the *OLD* address, the one just fetched (which is, as
    you can expect), the screen memory
  * Then, a bit later, *CAS falls, latching the high part of the
    address, while *WE is low.
  * Then, WE goes high again.

Thus, from the RAM's point of view:

  * read screen ram
  * ah, I see new data on address lines on 0-8 and a command to write data
  * Whoa!  It's 40nS later, and now I see new data on address lines
    9-17, so write the same data there as well, but I can't promise the
    old location got the data stored (my speed is 55nS, Mr. Designer)
  * Ah, 120nS later, *WE has been turned off, I will now read some data
    from the location I just wrote  (which is unneeded, but hurts nothing)
  * Repeat cycle

I kept wondering why I did not see a second write cycle, and why they 
were always doubled to the screen.  Luckily, the screen and low ram are 
in the same "bank" of 64kB in the MMU, and you cna see the screen, or it 
would have been hard to notice there was an issue for some time.

The fix (for those caring) was to gate *WE with *CAS.  Thus, the *WE 
line only becomes active once both parts of the address are latched to 
the SRAM.

I suspect my goof is not reading the DRAM specs, where it probably 
states that the the write won't commit until the CAS goes low, or 
something like that.

Jim