[Coco] GIME text modes and font data

[John Kent]

The character generator ius build into the 6847 VDG.
I assume the VDG design is included in the GIME chip.
In the 6847 VDG the RAM data from shared memory is used index the 
character in the ROM in text mode and the row address counter scans 
through the character rows.
The data output from the character generator is fed into a parallel in 
serial out shift register to form the pixel stream.
The color attribute is used to select the foreground and background 
color which is probably a color palette (lookup table) driven by the 
serial output data.
With the 6847 VDG there is no need for the 6809 to read a character 
generator.
I don't know enough about the GIME chip to know how that works.
If it's using the CoCo ROM as a character generator, it would have to 
read the RAM data and apply that to the CoCo address bus to access the ROM.
but as you say the character ROM appears to be in rather odd locations 
so generating the address offset would be messy.
The ROM output would have to be read off the data bus and loaded into 
the shift register.
The pixel clock is 8 x the CPU clock rate and I'm not sure that the 
memory would be fast enough to perform 2 accesses (the character code 
and the scan line look up) in the time of one CPU cycle.
$F39D - $F09D = $300
128 - 32 = 96 = $60
$300 / $60 = 8 = number of scan lines ?
I don't know if the GIME chip has a programmable character generator but 
if it did, it's possible that the 6809 could load the ROM image into the 
character generator.

If the pixel clock is say 14MHz in 80 column mode and the characters are 
8 pixels wide then the character access rate would have to be 1.75MHZ 
which is too high for the CPU.
My understanding is that the CPU clocks at less than 1 MHz lets say 
0.875MHz.
If you required an 80 character display you'd have to have a line scan 
buffer that loaded the characters in two scan lines.
If you had to look up the ROM in CoCo memory, then you'd have to have a 
double buffer, one for the character codes and one for the character pixels.

The MESS emulator does not need to do that character generation in real 
time.
Although It may need a character generator to generate the characters in 
the graphics memory, which I assume is what you are alluding to.
All it needs to know is the bit map so it is possible that it's cheating 
and using spare space in the ROM or registers for character generator space.

Just from first principles I would assume MESS is cheating.

John.

On 3/09/2012 5:29 PM, William Astle wrote:
> 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
>

-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent