[Coco] Coco 3 Memory Map Questions

RETRO Innovations go4retro at go4retro.com
Mon Feb 8 14:28:13 EST 2016


On 2/8/2016 12:35 AM, Dave Philipsen wrote:
> I know that the video memory must be constantly read by the GIME in 
> order to generate the display in real time.  And, the CPU can access 
> the memory without any wait states or contention with the video 
> access.  I think I've heard others explain that the GIME reads video 
> memory 16 bits at a time which effectively halves the number of 
> accesses compared to 8 bit reads. 
It does and it does not.

Normally, when one says that, they are noting that a 16 bit channel will 
present twice as much data in the same amount of time.

The Coco3 does that, except it doesn't.

It splits the memory into 2 banks, so it can bring in the data in 16 bit 
chunks.

But, it constrains itself to 8 bits slices of data.

So, to make the best of a non-optimal situation, it does the following.

When E is low, it supplies the correct row and column address during RAS 
and CAS.

As CAS goes high, the low byte of the 16 bit value is pushed into the 
GIME, and the upper 8 bits are latched into a '374 and then presented on 
the GIME data bus as soon as CAS reaches a high state.

THat all has to happen while E is low.

Then, when E is high, a different row and column is presented to the 
RAM.  The same process is followed as above, but if the request is a 
read cycle, GIME decides whether the high or low byte should be sent to 
the CPU.  If the request is a write cycle, GIME decides which bank to 
store the data, but the data is sent from the CPU to the RAM via some 
'244 buffers, the data is not sent through GIME, though it is presented 
to GIME via it's connection to the CPU data bus.




More information about the Coco mailing list