[Coco] GIME DRAM address mappings

[RETRO Innovations]

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