[Coco] GIME text modes and font data

[Bill Pierce]

William, I don't know if this helps, but I figured (just out of curiosity) since the Coco 3 runs in all-ram mode, I input a loop, poking 0s to the address ranges you listed, then I entered WIDTH80 and the text was there. Unless the Coco3 does some sort of ROM refresh in the switching then I would assume the hardware text does not come from the Roms. I didn't really think it did as I've used font programs that put new fonts in the HPRINT routines and they never affected the hardware text. Sounds like MESS cheated.
Again, out of curiosity, I tried the same with VCC, the text was there in 80 column mode. So VCC must have the hardware text in the right place.

Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Bill Pierce
ooogalapasooo at aol.com




-----Original Message-----
From: William Astle <lost at l-w.ca>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Mon, Sep 3, 2012 3:30 am
Subject: [Coco] GIME text modes and font data


I have a bizarre question for those of you who have delved into the 
workings of the GIME. The question is where does the font data come from 
when the GIME is generating its hardware text modes.

Let me be clear up front. I am NOT talking about HPRINT. I'm referring 
to the 40 and 80 column text modes.

What brings this up is the following:

I thought I would be cute and replace the ROM that mess uses for the 
coco3 with one of my own devising. That custom ROM uses the 80 column 
text mode. I was alarmed to find all the text showing up as spaces. A 
bit of experimentation revealed that mess is getting the hires font data 
from two portions of the ROM. Character codes 0 through 31 are coming 
from $FA10 through $FB0F and codes 32 through 127 are coming from $F09D 
through $F39C.

Now it seems totally illogical to me that the actual GIME hardware would 
be doing the same thing. The decode logic to make that work would be 
horrendously complicated. However, since I have neither the skills nor 
the hardware available to test how a real coco3 behaves when swapping 
out the internal ROM, I have no way to verify the behaviour.

In other words, is mess doing it right or is it just cheating and 
assuming that anyone using a non-standard rom image with mess is doing 
something unsupported and thus who cares if it doesn't work correctly? 
I'm leaning toward mess cheating but I have no way to prove it one way 
or the other.

Has anyone out there replaced the internal ROM in a coco3 with one that 
does not have the HPRINT font data at the standard location (that's the 
$F09D address)? If so, did it affect the 40/80 column text screens?

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco