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

[Robert Gault]

Bob Devries wrote:
> I get a dark grey screen with 16 short dark blue lines set at intervals 
> (horizontally) after which there are 8 light blue lines set at the same 
> intervals, the last 4 of which are under the first 4 dark blue lines. 
> The spacing appears to be approximately twice the length of one of the 
> short lines.
> 
> This is of course on my PAL coco3 (1MB).
> 

That is what I see but why are we seeing that?! The light blue pixels 
are set by the second loop which runs just 4 times. Why are 8 bytes 
changed by this loop?!


For anyone who has not thought about how the GIME functions, this 
clearly is a hardware issue and not a program bug. The bug in the GIME 
on what should be a 20 byte wide screen indicate some really strange 
action within this chip. Any of the bytes after the first sixteen that 
are changed also change bytes on the left side of the screen.
The service manual table for I/O at %FF99 would seem to indicate that 
the function of the bits are

Bit 7    6    5    4     3     2     1     0
     -  LPF1 LPF2 HRES2 HRES1 HRES0 CRES1 CRES2

With a value of %00000101 you have HRES0 and CRES0 which should give 20 
bytes per horizontal row, 4 colors, and thus 4 bits per byte for an 80 
pixel wide screen.
Well that's just how the left 16 bytes of the screen behave. It is not 
how the right 4 bytes of the screen behave. If you adjust the number of 
times the loop in line 40 runs, you should convince yourself that the 
right side bytes are still 4-color. But each right side byte controls a 
byte on the left side of the screen that is 4 bytes away on a linearly 
mapped screen!

If something that should be impossible seems to happen, it probably is 
not happening. You just don't understand what you are seeing. The best 
guesses on how HRES# works is as follows

HRES#     Width in bytes
111         160
110         128
101          80
100          64
011          40
010          32
001          20
000          16

This works correctly for most of the values. But if it does not work for 
some, does that mean the entire table is wrong and these bits do not 
directly control the screen width? Is the table correct but the GIME 
crippled because Tandy did not want to pay for full functionality? Are 
some other functions hidden in the workings of HRES# that the 
programming team hid from Tandy management?