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

[Robert Gault]

jdaggett at gate.net wrote:
><snip>
> 
> Robert
> 
> 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. 
> 
> james
> 
> 

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.
20 HSCREEN2:POKE&HFF99,WW
30 PALETTE1,25:POKE&HFFB0,7
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. :)