[Coco] GIME text modes and font data

[Bill Pierce]

Interesting, I didn't know parts of the Rom were readable in Ram mode. Must be a GIMI thang. They do a lot of crazy stuff with the MMU so it doesn't supprize me. I guess the fonts have to come from somewhere. In fact, I often wondered where the Coco 2 text was stored and if it was somehow accessable by some hardware hacking method to bring it into ram. Especialy after the last Coco 2s came out with true lower case VDG chips. I have one somehwere but it has a chip missing that I robbed for a fried one on my old Coco 3. Don't remember which chip it was but it had something to do with loosing video. It fried twice and I robbed a coco2 and a coco3 for repairs. The first time, it was reapired by a tech friend who worked on Cocos. He installed a socket in case it happened again and it did, so I did the repair then. It worked from then on for about 7 years till Hurrican Floyd fried a bunch of chips. Now I rob it for parts, most recently, a power supply :-)

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 4:08 am
Subject: Re: [Coco] GIME text modes and font data


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
>


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