[Coco] 256 color mode update

[Robert Gault]

Nickolas Marentes wrote:
> I have updated my website with some additional information regarding 
> this mystery.
> 
> Don't get excited, it's still a mystery. I just want to inform the CoCo 
> community of any possible hints towards solving this mystery.
> 
> Go to  my 256 color mode page at....
> 
> http://members.optusnet.com.au/nickma/ProjectArchive/256mode.html
> 
> ... and read the additional sections titled "Palette Bypass Found?" and 
> "The Motorola R.M.S. Chipset. Precursor to the GIME?"
> 
> The first article is courtesy of Robert Gault.
> 
> Nick Marentes
> 
> 
> 

That is actually info from an e-mail message and as such was not proof 
read as carefully as it might have been. The lines
" The above data applies when $FF90 is set for Coco3 %1xxxxxxx. What I 
have found is that when $FF90 is set for Coco1&2 %0xxxxxxx, the above 
table for HRES has different meanings."
are backwards and should read
" The above data applies when $FF90 is set for Coco3 %0xxxxxxx. What I 
have found is that when $FF90 is set for Coco1&2 %1xxxxxxx, the above 
table for HRES has different meanings.

Further as with most e-mail of this type, it is a snapshot representing 
my thinking with the data then available. That data was not sufficient 
to distinguish between all interpretations and I chose what I wanted but 
the wrong one.

  When in Coco 1&2 mode ($FF90=%1xxxxxxx) palettes $FFBA-$FFBB determine 
the PMODE4 screen colors. $FF9A determines the border color for all Coco 
modes.
  As PMODE4 is two color, each bit of a screen address determines the 
palette for that pixel. The original testing was made with $FFBA=$3F and 
$FFBB=0. The screen data in my test was controlled by the code loop
  clra
b@ ldx #disply
  adda #$11
a@ sta ,x+
  cmpx #$ffe0
  bne a@
  bra b@
  This loop was expected to change the screen rapidly with a variety of 
vertical stripes. In Composite mode this would yield artifact color and 
in RGB mode white and black stripes. However, what happened was a very 
slow flip between an all white or all black screen. I thought the 
palettes had been bypassed which at first glance seemed reasonable.
  Further testing where $33 (RGB yellow-green) was one of the colors 
proved that the palettes were still active even though there were no 
vertical stripes.

  The effect of HRES=1xx clearly corrupts ('86 GIME) how the video 
system responds to the screen data. How could one explain the lack of 
the vertical stripes for the above code? Eventually I realized that the 
extended delay in flipping between colors was a clue.  Strange as it 
might be, perhaps only two values of the 256 possible for each screen 
byte functioned!
  What actually happens is that all screen bits are ignored except for 
%1xxxxxxx. This can be proved if the above routine is changed to
  clra
b@ ldx #disply
  adda #$80
a@ sta ,x+
  cmpx #$ffe0
  bne a@
  bra b@
the screen rapidly changes between the two chosen colors.

The above effect of $FF99 can be negated with the video behaving 
normally as a PMODE4 screen if the SAM bytes at $FFC0-$FFC5 are set for 
DMA mode:
  sta $ffc1
  sta $ffc3
  sta $ffc5

===============

  Does this help with the search for the 256 color mode? Maybe not, 
although it does demonstrate a bug/feature of the '86 GIME.
  It does stress that regardless of our abilities in any field of 
endeavor, it is very easy to jump to the wrong conclusions when we have 
inadequate data.