Some time ago, I played with a "flicker" technique on the CoCo that alternated screens between a 9-color (8 + black) "Semi-Graphics" mode and a 4-color "Color Graphics" mode on the VDG. I combined that with a technique for teasing 8 on-screen colors out of the 4-color mode, giving a combined effect of 44 on-screen colors! I then used this technique as the basis for showing puzzle pictures in Sluzzle, and there was much rejoicing...
Not long after that, I conceived of a similar technique that might solve at least a few of the problems with the 44 color technique at the cost of reducing the palette size a bit. I let that sit dormant for a while, until I decided to play with it a bit during my 2014 year-end break. Below I will describe the 35 color technique for those interested in hearing more.
Problems Abound
The main problem with the 44 color "flicker" technique is, of course, the flicker. The mode toggles between the two base video modes (SG24 and G6C) at the vertical refresh rate (60 Hz on NTSC machines, 50 Hz on PAL machines). This produces a noticeable flicker effect on the displayed screen, but unfortunately this is inherent to any "flicker" technique -- sorry!
The bigger problem with the 44 color technique is that it uses the aforementioned technique to get 8 on-screen colors from the 4-color modes of the VDG. This is achieved by switching the colorset select (i.e. CSS) input to the VDG
while a line is being drawn on the screen! This changes between the two 4-color palettes as much as 8 times per line, doubling the amount of available colors on the screen. (This 8 color technique is also used in the CoCo version of the Imagic game Dragonfire.) Unfortunately the extra colors come at the cost of eating-up all of the available CPU while the 4- (now 8-)color screen is being drawn.
The other big problem with the 44 color technique is that only one of the base modes offers the (non-)color black. Since the observed color at a given position is the average of the colors at that position on the two base screens, then no position will ever be observed as fully black. Although the available dark blue is a workable substitute in many case, the lack of a true black is a big handicap for the 44 color technique.
Another Option
If we accept that we will only get 4 on-screen colors from the 4-color base screen, then we could free-up more CPU time while that screen is displayed. This would allow more time for implementing a game, playing background music, or whatever else. But what about black pixels?
It turns out that on NTSC CoCos (and Dragons), there is another option. Due to how an NTSC video signal encodes color (and how the CoCo video circuit is implemented), the black and white 256x192 VDG mode (G6R) is effectively a 128x192 4-color mode offering black, white, "blue" (cyan?), and "red" (orange?) pixels. This mode was very popular for commercial games on the Coco, and it is similar to using 4 of the 6 available colors in the high-res video mode of the Apple II.
So now we can use a "flicker" technique to alternate between the G6R (i.e. PMODE4) "artifact color" mode and a Semi-Graphics mode. Since the G6R mode also offers black and white, both of those colors are still available when using the "flicker" technique! I will show the available palette below.
 |
| Semi-Graphics Palette |
 |
| G6R "artifact color" Palette |
 |
| Combined "Flicker" Palette |
Issues Remain
As you can see, this technique yields a nice range of usable colors from the VDG. It does, of course, still have a perceivable "flicker" on the screen. Also, the technique is limited to being used on NTSC displays. Of course, the G6R mode can be used as a 2-color mode on PAL machines -- by ignoring the "artifact" colors, this could also be viewed as a 17 color technique...
Sticking with the NTSC world, there is one other problem. Anyone familiar with the use of "artifact" colors on the CoCo will know that the patterns corresponding to "blue" and "red" switch at random between resets. That is why so many CoCo games have an introductory screen with a message like "reset until this is blue". Any program using the 35 color technique described above will need to address the same issue.
Finally, I am seeing some distortion to the colors near the top of the display. I have not yet determined why that is happening, and it might relate to something else I am doing -- YMMV. I'm going to downplay this distortion for now, as I believe it is likely caused by something outside the core of the technique described herein.
 |
| 44 Color Me |
 |
| 35 Color Me |
Nevertheless, I am getting decent results in my picture conversions using this 35 color technique. The availability of a true black makes a huge difference, and that largely compensates for the ~20% smaller color palette available versus the 44 color technique. With a lot more CPU time available, this technique could be useful for any number of programs on the CoCo including games.
I'm not planning to do anything more with this technique right now, but I hope someone else finds it useful. I'm happy to consult with anyone that wants to try to make use of it. In any case, be sure to stay tuned... :-)
