[Coco] What do you make of this non-approved HSCREEN mode?
robert.gault at worldnet.att.net
Sat Jun 13 20:18:18 EDT 2009
jdaggett at gate.net wrote:
> 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.
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.
More information about the Coco