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

[Paul Fitch]

Seems to me that in order to fully understand what is going on, you have to
treat the mode as a "Black Box".  Ie, you give the "black Box" every
possible input, and record every possible output.  Then once you know what
is happening in the real world versus what the GIME documentation says
should happen you could start to construct a model of the "real" hardware
and compare that to the "ideal" hardware your GIME docs say you have.

I know you are asking people what they "see" when the program runs, but are
you mapping the actual screen memory values for those bytes/pixels as well?
There may be more going here than your eye can tell you.  If the GIME is
writing to unanticipated areas on the screen, it could be doing it elsewhere
as well, and not on the screen memory that you can see with your eyes.

> -----Original Message-----
> From: coco-bounces at maltedmedia.com 
> [mailto:coco-bounces at maltedmedia.com] On Behalf Of Robert Gault
> Sent: Sunday, June 07, 2009 7:37 AM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] What do you make of this non-approved 
> HSCREEN mode?
> 
> 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?
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>