[Coco] GIME text modes and font data

[William Astle]

On 12-09-03 01:53 AM, Bill Pierce wrote:
>
> 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.

No, mess doesn't take it out of the RAM. It takes it out of the ROM. The 
ROM/RAM copy doesn't even come into play here and changing values in the 
RAM copy will not affect anything.

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.


>
> 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
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>