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

[jdaggett at gate.net]

On 9 Jun 2009 at 21:44, Robert Gault wrote:

> 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. :)
> 

Robert 

keep going. The best way to understand how the internals of a black box 
works is by tickling its inputs and looking at what the outputs do. I starting 
to digest what you have here. This is a first beginning to try and decipher 
the internal workings a bit more. 

james