[Coco] GIME DRAM address mappings

[Dave Philipsen]

Ok, so now I think I understand why you are concerned about how the GIME 
accesses the SRAM.  I guess the fact that the GIME is specifically made 
for DRAM and not SRAM kind of muddies things up for you...


Dave


On 9/28/2017 10:10 PM, RETRO Innovations wrote:
> On 9/28/2017 10:29 AM, Dave Philipsen wrote:
>> So, Jim, if I understand correctly you are creating a 2MB memory 
>> expansion that will use the upper 2 unused bits in the MMU registers 
>> to access the entire 2MB, right?  Will your board use SRAM or DRAM?
> Right now, the board has 4 MB, mainly so I can work on how to add more 
> than 2MB support. 2MB uses all 8 bits of the task registers, ala Disto 
> and others, but adding more than 2MB requires a new strategy, which I 
> planned to use the board to design (I have ideas on how to do this).  
> If I am successful (which is a big IF, since I have but an entry level 
> understanding of GIME memory accesses and, as such, have this memory 
> issue I am debugging), the idea I am considering would allow 16 bits 
> for the task register, support an optional, more granular banking 
> scheme (4kB pages), support a "Read Only" bit to force an IRQ if a 
> page is marked as such and a write is attempted, and allow at least 
> 16MB of 4kB paged RAM with write protection.
>
> The board currently uses SRAM, to avoid having to deal with refresh 
> cycles and such, but DRAM is not ruled out (fast paged DRAM or DDR 
> type DRAM could be used, and would also be power use friendly).
>
> I promise to bring the board to Tandy Assembly, but I can't guarantee 
> it will be completely working (even as a rudimentary 512kB 
> expansion).  Right now, the main goal is to better understand GIME 
> memory accesses.  I might have to backtrack and build a triad-like 
> board to figure out DRAM-to-SRAM conversion, and then go back to this 
> board.
>
> But, on the plus side, I have another project I will bring that is 
> working (at least it passes all the tests I threw at it) dealing with 
> memory and the Coco.
>
> I shuold just give up on this design for TA, and focus on getting 
> other stuff ready, but I can't seem to focus on other things until I 
> can at least figure out where I am going wrong on this design. I have 
> replicated the entire 16-to-8 multiplexing scheme that's on the Coco3 
> memory bus on my PCB, but somehow, any write to memory is showing up 
> as a write to a suitable spot on the screen.  For example, if you poke 
> a value to location 512, it will show up at 1024 (first spot on 
> screen) as well.  Poking a value to 2048 will also darken that spot on 
> the screen.  I have been poring over logic analyzer trace output for 
> the past few night, learning so much about the GIME memory cycles, but 
> not making much progress towards finding my issue.
>
> In the pic on Facebook, for example, DECB writing to location 148 
> translates to a $70094, which looks like this on the wires:
>
> CAS     RAS
> B5     B3     B2     B1     B0     12     11     10     9 B4     8     
> 7     6     5     4     3     2     1     0
> 8     7     6     5     4     3     2     1     0     8     7 6     
> 5     4     3     2     1     0     W
> 1     1     0     0     0     0     0     0     0     1     0 1     
> 0     0     1     0     1     0     0
>
>
> To put in a more human-friendly order:
>
> B5     B4     B3     B2     B1     B0     12     11     10 9     8     
> 7     6     5     4     3     2     1     0
>
>
>
>
>
>
>
>
>
>
>
> 1     1     1     0     0     0     0     0     0     0     0 1     
> 0     0     1     0     1     0     0
>     7     0     0     9     4
>
>
> But, the screen also sees the write at $70494:
>
> CAS     RAS
> B5     B3     B2     B1     B0     12     11     10     9 B4     8     
> 7     6     5     4     3     2     1     0
> 1     1     0     0     0     0     0     1     0     1     0 1     
> 0     0     1     0     1     0     0
>
>
> Again, more human readable version:
>
>
>
>
>
>
>
> B5     B4     B3     B2     B1     B0     12     11     10 9     8     
> 7     6     5     4     3     2     1     0
>
>
>
>
>
> 1     1     1     0     0     0     0     0     1     0     0 1     
> 0     0     1     0     1     0     0
>     7     0     4     9     4
>
>
> 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... :-(
>
>
> Jim
>
>
>