[Coco] GIME text modes and font data

[jdaggett at gate.net]

On 3 Sep 2012 at 2:07, William Astle wrote:

> And if the real coco3 does the same idiocy that mess does, it would also
> be taking it out of the ROM, not the RAM. Just like how FFFx is hard coded
> to always come from the internal ROM regardless of the rest of the memory
> mapping, the font data access would have to be as well.

Wiliam

The GIME supplies the hard coding for addressing the range FFFx into ROM. The thre SBus 
lines somewhat mimic the MC6847 of the COCO1/2 but not totally the same. When its value 
is $0, the ROM is accessed. With the GIME chip, the 256 bytes from FE00 to FEFF are can 
be mapped as RAM as controlled buy the state of the MC3 bit in register INIT0 at FF90.

The MC1,0 bits control how much ROM is mapped into memory and whether it is internal or 
external. This can be 16K internal, 16K external, 32K internal or 32K external. When 32K 
external ROM the vectors at FFFx are still mapped to the internal ROM. 

Also the Hi resolution text window is at $6C000 to $6E000. This coresponds to C000 to E000 
with the MMU set to $36 at FFA6 in the GIME chip. The GIME chip has a neat way of moving 
code from ROM to RAM by just changing the MMU value for the given 8K range. The GIME 
defaults to mapping $70000 to $7FFFF for its initial 64k map. Changing any of the 8 bytes in 
the MMU registers will map in other ranges. 

The MMU allows for a lot of what would be on appearance as crazy. But with paged MMU 
you can do a lot of crazy things. You can write to a 8k block then copy it to any other 8K block 
in the memory map of the system. A nice feature with 512K of ram and windows. Each 
graphic or text screen can have its own block of ram. You also have the two other registers in 
the GIME that tells the GIME chip where the start address for video ram begins 
(FF9D/FF9E).This can actually allow the video section to start on any 8 byte boundary within 
the memory map of the COCO3.  

james