[Coco] What do you make of this non-approved HSCREEN mode?

[Robert Gault]

jdaggett at gate.net wrote:
> On 7 Jun 2009 at 23:20, Robert Gault wrote:
> 
>> Robert Gault wrote:
>>
>>> So, ignoring the comments that don't apply to the program in
>>> question, you are saying there are bugs in the GIME design?
>>>
>>> Do you think that in Coco3 graphics mode an HRES=000 is 20 bytes
>>> wide or just too buggy to be anything?
>>>
>> Sorry that should have been HRES=001 is 20 bytes per row.
>>
> 
> 
> And HRES 000 yields 16 bytes per row. 
> 
> WHile the register will hold the encoded bits, the actual decoder for the 
> horizontal resolution bits may not fully be implemented. Having the register 
> bits is small real estate on the die. The actual decode and implementation 
> takes more area and thus cost. 
> 
> The simplest usage of the HRES bits is to feed them into a 3 of 8 decoder 
> and then use those as an address lines to ROM that is 8 by 10 bits wide in 
> size.  The output of the ROM then feeds a comparator that takes the row 
> bytes per row counter output as the other input. When the two are equal 
> then the vertical line counter is incremented and the row counter reset. So 
> what ever gets programmed into the small ROM is what is displayed. 
> 
> james
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 

What I've been able to see with an actual Coco3 in Coco3 mode ($FF90), 
graphics mode ($FF98), and $FF99=5 (20-byte width, 4-color) follows.

The screen is a true graphics screen only for the middle 5-15 bytes of 
each horizontal line. Bytes 0-4 are unique in that they only have an 
effect on themselves. Bytes N*(16-19) - where N>0 - effect themselves 
and the next group of bytes at N*(20-24).
The screen is not usable in any practical sense as pixels are not round 
but look like short lines. If there is any interest to be found here, it 
is a hint into the workings, or lack of, inside the GIME.