[Coco] Re: Color Computer 3 prototype

John Kowalski sock at axess.com
Fri Jan 21 16:58:38 EST 2005


Robert Gault wrote:
>John, I'm not convinced your example is correct. With 252 and 255, you
>are telling the GIME to use a screen that is 640x255 with 2 color
>resolution (252) or undefined color resolution (255). The first screen
>is quite normal and you can almost draw on it with the high res graphics 
>commands.
>
>The second should be very unpredictable as the GIME has not been given a
>color resolution.

Hi Robert,

Actually both are undefined.  If we extend the pattern of valid resolution &
bit-depth selections into the undefined;
252 may be interpreted as 1280x225 in two colors.
255 may be interpreted as 160x225 in 256 colors.

Since neither of those modes exists officially, the GIME does unpredictable
things.  But the message was really into looking into what it was that the
GIME was actually doing in these modes.  255 would appear to at least be
partially running as if it were in 256 color mode - at least internally,
just not displaying any graphics.
252 appears to disable the graphics bit shifter - and in effect displays
what is actually 80x225 resolution, displaying ONLY bit 15 of each *WORD* of
RAM.  Try writing to odd address memory locations - nothing will appear
on-screen.

Anyway, the point was to suggest that maybe parts of the production GIME may
still be processing graphics data as it should if a 256 or High color mode
existed, only that other parts (like actual pixel generation, or color
mapping) are missing or disabled.


> PS. Here is an example that draws a diagonal "line" using 8 pixel at a 
> time to keep things simple. That should indicate that the screen is a 
> normal high res graphics screen.
> 
> 10 HSCREEN2:POKE&HFF99,252
> 20 FOR I=0TO159
> 30 LPOKE&H60000+I+I*80,&HFF
> 40 NEXT
> 50 GOTO50
>
>If you want a better straight line you will need to step through the 8
>bits per byte with an inner loop.

Not quite...  Your example assumes an 80 bytes per line mode, but this mode
actually displays 160 bytes per line.  You don't see the mirrored line
because odd-address bytes do not display in this mode.

Also, if you try stepping through the 8 bits per byte, you will see that
only one of those bits actually works.  The other 7 (plus all 8 in
odd-addressed bytes) are totally undisplayed.

                                         John Kowalski (Sock Master)
                                         http://www.axess.com/twilight/sock/




More information about the Coco mailing list