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

[jdaggett at gate.net]

On 11 Jun 2009 at 23:21, Robert Gault wrote:

> To round out this thread, we should look at the screen produced by
> HRES=000 or 16-bytes per screen. It behaves normally with CRES set for
> 2 or 4 colors. The fun begins with CRES set for 16 colors. There
> should be two pixels per byte but you don't see a screen which looks
> like that.
> 
> 10 HSCREEN2:POKE&HFF99,2
> 20 PALETTE1,24:POKE&HFFB0,7
> 30 M=&H60000
> 40 FOR I=0 TO 3056 STEP 16
> 50 LPOKE M+I,36:LPOKE M+I+1,36:NEXT
> 60 FOR I=0TO15:LPOKE M+I,129:NEXT
> 70 GOTO 70
> 
> You should see two vertical bi-colored columns separated by the screen
> background and on the top horizontal line 16 two color dashes.
> 
> It seems the screen is 32 bytes wide with 16 bytes accessible for
> drawing. The inaccessible area is filled with the palette #0 color and
> alternates with the accessible areas.
> 
> ==========================================================
> 
> It would be nice if these weird modes were a window on the GIME 
> circuitry. I'm not a hardware guy so I can't give an educated guess.
> To me, it looks like some incomplete look-up table is being used.
> Garbage in gives garbage out.
> 

Robert

After looking back at the MC6847 spec and digesting what your program is doing, it appears 
you are trying to implement the CG1 mode of the COCO1. IF so then you have stumbled on 
a GIME defect and would explain why some of the modes of the COCO1/2 were never 
implemented. SOmetimes that happens. When it does you tell the world nothing and hope 
that they don't stumble across it. Then it is an usupported function of the chip. 

Looking back at CG1 mode it is 64 pixels by 64 pixels. Instead with the GIME chip it 
appears to be 64 pixels by 192 pixels. Or maybe 128 by 192 pixels. 

james