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

[Robert Gault]

jdaggett at gate.net wrote:

> 
> Robert
> 
> After looking back at the MC6847 spec and digesting what your program is doing, it appears 
> you are trying to implement the CG1 mode of the COCO1. IF so then you have stumbled on 
> a GIME defect and would explain why some of the modes of the COCO1/2 were never 
> implemented. SOmetimes that happens. When it does you tell the world nothing and hope 
> that they don't stumble across it. Then it is an usupported function of the chip. 
> 
> Looking back at CG1 mode it is 64 pixels by 64 pixels. Instead with the GIME chip it 
> appears to be 64 pixels by 192 pixels. Or maybe 128 by 192 pixels. 
> 
> james
> 
> 

I'm not trying to implement any SAM modes. These mode sizes may be the 
same as some of those produced by the paired MC6847 plus MC6883, but 
that is just co-incidence.

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.

It might be that the GIME can't decide whether it should be working in a 
COCO1 or COCO3 mode. It might be that certain combinations should have 
been locked out but weren't. It might be that there are bugs in the mode 
implementation that were never corrected. If we are very lucky and I 
doubt it, there may be some back doors via these non-approved modes that 
will lead to something spectacular.

Which of these possibilities is likely, I'll leave to the hardware 
specialists to argue over. To my knowledge, a systematic exploration of 
these settings on Coco3 has not been done before. An accurate 
description of the results could provide a valuable assist to the study 
of the prototype boards.