[Coco] Re: Color Computer 3 prototype

[Robert Gault]

Further testing of this ($FF99=252) mode shows that every other screen 
byte is active and that only bit 7 of the even bytes causes color 
change. The palettes used are $FFB0 and $FFB1 and the pixel is 8x1 
almost like a semi-graphics mode. Therefore, as is, the effective screen 
size is 80x255 using two colors with 8x1 pixel size.

How this might relate to a 256 color mode is questionable unless there 
are some other secret POKEs that can activate more bits for color selection.

The above represents the results of testing with an '87 GIME. John, have 
you found the same results with either '86 or '87?

John Kowalski wrote:
> 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/
> 
>