[Coco] What do you make of this non-approved HSCREEN mode?
robert.gault at worldnet.att.net
Tue Jun 9 21:44:22 EDT 2009
jdaggett at gate.net wrote:
> That is interesting find. Yes there are settings that become meaningless. I
> do agree that they should have not been implemented if it is not going to be
> supported or of use.
Here are two other modes that don't behave as expected. They are the
160-byte and 128-byte 2 color modes. The hardware can't be expected to
scan fast enough to yield 1280 or 1024 pixels and it is not clear
exactly what it is doing.
The following program will demonstrate that these modes are one "pixel"
per byte. Unfortunately that does not mean 256 colors. :) There is only
one active bit determining the palette register, bit-7. If bit-7 is not
set, the color is palette #0. If it is set the color is palette #1.
It might be more accurate to say that the pixel is not round but 8 by 1.
Or put another way, all 8 pixels in a bytes are either color #0 or color #1.
1 W=160:WW=28: REM Or use W=128:WW=24
10 M=&H60000:PX=2^7 REM Use any other power of 2 as a test.
40 FOR I=0TO W-1:LPOKE M+I,PX:M=M+W:NEXTI
50 GOTO 50
This may or may not add to our knowledge of the GIME circuitry. Who
knows, if we completely characterize the unauthorized modes, we might
find something exciting. :)
More information about the Coco