Thursday, January 1, 2015

35 Colors On NTSC

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... :-)


  1. that's alot better over the 44 color.... (black makes a huge difference here)...

    also glad to hear that it's not nearly as cpu intensive as the *per line* stuff.....

  2. You're getting a color distortion because the CoCo outputs a different colorburst signal in the "B&W" PMODE4 mode than it does in normal color modes. The colorburst is the NTSC color reference signal at the beginning of each scan line (outside the left border). It takes most TVs/monitors about 10 scan lines to 'realign' if the reference signal suddenly shifts like that.

    You're switching between "B&W" and color modes on the first line of the 192 line display area. The distortion starts on line 1 until about 10 lines down. If you changed your code to time the mode switch earlier in the top border, preferably during the vertical blanking, the distortion would go away, outside the visible area of the screen

    PS: there is a magic trick you can pull off by abusing this side effect.. say you *impose* the PMODE3 colorburst signal into PMODE4... or vice versa.. You could then display entirely new sets of color. PMODE4 would have Black, White, Green and Purple. PMODE3 / SG color sets would also shift hue by 90 degrees from their normal colors.

  3. John,

    Can we have source code? I think that if you used two alternating Semigraphics 24 modes you could still get some compelling results. I like the process of palette matching and character/semigraphics/pixel selection but would love the leg up on the display routine on the TRS-80 itself. First off I would just like to be able to see it using my Drivewire on its own. I have a composite output mod to install but RF should still be a lot of fun. Never-the-less I have the Coco-2 64k hooked up, I've got my Drivewire configured, Got my USB to Serial cranking and once I get my composite mod going then I have a great credible capture route. Plan is to make a converter that displays images in each of the available TRS 80 Coco 2 modes. My interest is in Semigraphics - so we will see where that takes me. Anyway, a leg up with code and a description of your dev environment would be great. My ASM experience is all Z80 - so this CPU/architecture will be new to me.

    1. The 35-color stuff remains a hacked-up mess in my local repository. I should clean it up, but I'm lazy... ;-)

      The 44-color stuff from earlier in this blog is available, as is my puzzle game Sluzzle, which is based on that same work...

      I hope that is helpful to you!