[Coco] GIME DRAM address mappings

[David Ladd]

Jim,

Are there schematics of the NOCAN3 board that has the larger amount of RAM
on it?  Maybe how that worked might shed some light on the topic?

+-----------------------------------------------------------------------+
| David Ladd a.k.a. PacoOtaktay a.k.a. Drencor                          |
| YouTube: http://www.youtube.com/user/PacoOtaktay                      |
| YouTube Gaming Live: https://gaming.youtube.com/user/PacoOtaktay/live |
| Websites: http://dwladd.com     &     http://www.theterrorzone.com    |
| G+:  https://plus.google.com/113262444659438038657                    |
| G+:  https://plus.google.com/+DavidLaddPacoOtaktay                    |
|                                                                       |
| Do you have your CoCo 3 yet?                                          |
+-----------------------------------------------------------------------+


On Thu, Sep 28, 2017 at 10:10 PM, RETRO Innovations <go4retro at go4retro.com>
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
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>