Playing With Video Part II by John Kowalski (Sock Master)
** Breaking the 16 color barrier - displaying 64 simultaneous colors **

*NOTE: This program does not work with the CoCo3 emulator*

Last time I showed you a tiny program that ran as a background CPU task while
BASIC was running as usual in the foreground.  The program simply kept itself
syncronised with the video and kept generating palette changes in one of the
palette registers every few scan lines - causing a rainbow effect on screen.

This time around, we're going to take palette changing a little further.
Everyone knows that the CoCo3 can only display 16 colors at a time - this is
quite limiting when it comes to trying to display images with lots of shades
or variations of colors.  Although the '16 colors at a time' limit is very
real, what would happen if we tried changing all 16 palettes in the middle
of the screen?  We would end up with 16 colors on the top half of the screen
and a different 16 colors on the bottom half of the screen.  There, we just
broke the 16 color barrier - there are 32 colors on screen.  Is it useful?
Not really, unless you want to display two different 16 color images, one on
the top half of the screen and one on the bottom.

We need to do better than that to get a useful display.  It just happens to
turn out that the 6809 in the CoCo3 CAN manage to alter all 16 palette
registers each and every video scan line with some clever programming.
(The clever programming mostly has to deal with the fact that changing
palettes causes 'palette glitches' to appear on the screen - if we were
changing the palette 16*192 (3072) times per video frame, there would be
3072 glitches on the screen.  The way to avoid palette glitches is to change
the palette in the time when the screen border is being displayed.  The
problem is that there are only 34 CPU cycles in the horizontal border of
each scan line.  You have to generate 16 palette changes in 34 cycles - or
one palette change every 2.125 CPU cycles to avoid palette glitches.)

Well, this program does it.  The technique gives you the ability to display
images with 64 colors in them, but limits you to using only 16 colors per
scan line - but each scan line can have a different set of 16 colors.
Luckily, it's unusual to need all 64 colors in one scan line - but the
picture I've used as a sample did require more than 16 colors per line.
I had to make a program to analyse the colors used, and only use the 16 most
commonly used colors of each scan line and drop the least common >16.  It
turned out pretty well, although you can notice a few minor color errors in
the picture if you look closely (you can notice a yellow streak in the
rabbit's left foot for example).

Conclusion?  It definately looks prettier than 16 color images, but when it
comes down to it, 64 colors is still not enough to get very good shading in
pictures.  It IS an improvement, and I wish this technique were used more
often in CoCo programs.

Next time I will attempt to break the 64 color barrier.  I'll take the next
step in video tricks and generate a 343 color display!  (7 shades of red,blue
and green.  7*7*7=343 colors.)

For those of you who want to tinker with the program, I've provided the
EDTASM source code of the ML driver (SHOW64.ASM).  The 3072 byte palette
table is located at $0F00 and it uses the HSCREEN2 area to store the graphics
image.  Try adding FORA=3840TO6911:POKEA,255-PEEK(A):NEXT before the exec in
line 240 if you want to view the sample images in NEGATIVE colors!