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

[jdaggett at gate.net]

On 13 Jun 2009 at 20:18, Robert Gault wrote:

> What I tried to do was complete the missing entries in the Tandy table
> for $FF99. Based only on what Tandy gave in the service manual, there
> appears to be two sequences alternating in the HRES bits of $FF99. One
> series is 640, 320, and 160 (width in pixels). The other series is 512
> and 256 (width in pixels). Translated into width in bytes, that gives
> the two series of 160, 80, 40, 20  and  128, 64, 32, 16.

Robert

16 bytes per row is the basis for the CG1 mode of the COCO1/2. If you 
have 8 colors that will be one color per pixel and 8 pixel sper byte. Thus the 
screen is 128 pixels. 16*8. Four colors is four pixels per byte and 64 pixels 
and 64 pixels across. I beleive that 16 colors at 16 bytes per row is not a 
Coco1/2 mode. That introduces an interesting situation. The GIME has 
more video modes than advertised but not all may work as expected. 

This could be from incomplete decoding or a look up table not fully 
implemented to logic that does not work. Still it is interesting to poke and 
prod the GIME chip to see what it does or does not perform as expected. 

james