[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