NTSC demystified - Implementation - Part 5

Now that we understand how NTSC color coding works and the math behind it, its time to think of ways to implement color coding. Knowing the math helps because that knowledge equips us to abuse the system and code color using simpler/cheaper hardware.

Recapitulating, the NTSC video signal consists of two components, the luma signal which tells the TV the brightness of a "pixel" and chroma signal which tells the color of the "pixel". The luma signal is simple enough. Higher voltage levels represent brighter spots while lower levels represent darker spots. The chroma is a tad more complicated. Color information is QAM modulated onto a subcarrier wave.

Some of techniques used to generate NTSC color are

1. Doing the QAM modulation in analog hardware. With all the recommended filters, this easily produces the best results. Whats more, the input can be in the form of RGB which is a big advantage over doing something in some unknown color space. The AD725 does this. The drawback is that its rather expensive and takes out most of the fun from NTSC color generation. Hobby projects are most often fun because of the DIY nature of the project. Having an ASIC do the job is a downer for me.

2. Putting out square waves instead of sine waves and controlling the phase of the wave. Achieves really good results. Most suitable on an FPGA where a phase accumulator can be easily designed. Implementing PAL is also quite easily possible. See [2]

3. A variant of #2 that uses discrete hardware. A series of NOT gates or buffers can be used to create phase delays. Various points on the delay chain are tapped and fed to a multiplexer. The microcontroller selects which phase to be output at that point of time so that the "pixel" has the color its supposed to. Needs a LOT of hardware and wires. You are left at the mercy are delay variations over temperature , manufacturer and batch of the chip. See [3] , [4] and [5].

4. A variant of #2 that uses SPI to create phase delays. This easily requires the least hardware. At high enough SPI Clock, a wide range of colors can be obtained. At 28.636Mhz ( 8 x Fsc ), 8 phases can be created. This allows for 8 "pure" hues and a number of mixtures, many of which are identical. This technique is great but there is a slight catch. If implemented as per NTSC spec, each line is 227.5 cycles long. So the phase of the color burst inverts if you take the sync tip as reference for each line. Implementing this inversion happens automatically with other techniques. But with SPI, this has to be done manually. When using this technique, this inversion is ignored and the length of each line is rounded to either 227 or 228 cycles. But this results in poor color transitions with distinctly visible bands at transitions. See [6] , [7].

Here's one technique I came up with that no one has used so far.

5. A digital variant of #1. The idea is create different phases of the color carrier ( either by a delay chain or ring counter ) and instead of multiplexing the outputs, we add the phases in a manner that can be controlled digitally. I've been able to get this to work on LPC1768 and Atmega16. I'll publish the results soon. It requires minimal extra hardware and enables even the slowest 8-bitters to generate NTSC color video.

It may look a little too much to implement with discrete circuits, but with a few tricks, a very simple circuit is possible.

References
1. AD725 Datasheet
2. PAL using FPGA
3. XGS AVR
4. Lazarus-64
5. Atmega64 GameStation
6. RBox
7. Apple II graphics