[Coco] GIME text modes and font data

[William Astle]

To answer a couple of questions in there:

The character width is 8 pixels. The HPRINT font uses 8 rows per 
character but the GIME can do up to 12 rows per character. I assume rows 
9-12 are blanks.

As far as what mess is doing: it appears to be using the HPRINT font 
data in the ROM as the bitmap data for the hardware font. I know it is 
doing that because I had mess use a different ROM (which it complained 
about but let me proceed) which had various patterns in the various 
relevant address ranges and those patterns showed up on screen in the 
text modes instead of proper characters. Given that your assessment 
agrees with mine (from first principles), I assume mess is cheating 
since I don't see how the real hardware could be doing what mess is doing.

On 12-09-03 02:53 AM, John Kent wrote:
>
> 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
>>
>