In composite video, a scanline has the following format:
Every line has:
- a sync mark, which is the lower level, on the left.
- a color burst, which I'll explain below.
- video data.
The sync mark is used to tell the TV set to bring the beam back to the left side of the screen.
At the time TVs were black and white, you had the sync mark and then the video data. The amplitude of the data signal would determine how bright the pixel is during the length of the line (63.5µs in NTSC).
When color TV tubes were created, it was important to keep compatibility with B&W sets when broadcasting TV programs.
The idea was to add the color information 'on top' of the B&W information so that it would not be visible on B&W TVs, but color sets would be able to get the color data.
In practice, if you take a B&W TV and hook an Atari 2600 where you can toggle color / B&W you will notice that the color display adds a bit of noise to the image. That's the color info that the B&W TV doesn't process. That same noise is present in the early color sets, but not the more modern ones.
Since the amplitude of the signal would determine the luminosity, the system was design so that color is encoded as a phase shift from a reference signal.
This signal has a very small amplitude, so it will not damage too much the luminosity signal (although it does a bit as you can see with the atari 2600 test).
In order to calculate the phase shift, you need a reference. It comes in the form of the color burst. It consists of roughly 2.5µs of a signal at 3.57954545 Mhz (the NTSC carrier frequency).
The TV set has an oscillator at exactly the same frequency. When the signal is detected, the TV's oscillator gets synchronized, through a PLL, so that the two signals are now in phase.
Every scanline re-synchronizes the internal oscillator.
On top of the luminosity signal, the same 3.57954545 signal is added, but each color is represents by a phase shift from the color burst reference.
This chart gives an idea:
So far so good. Now let's talk about artifacts:
The NTSC color clock runs at 3.57954545Mhz and the full range of colors can be represented through phase shifts through the whole 360º.
The system works well as long as each pixel lasts long enough so that the color signal can be set to any value.
But what if the pixels are output at a rate of 2 x 3.57954545Mhz?
Now two pixels will share the time to express one color and, if the pixels are very different in luminosity, the system may interpret differently the phase of the color signal and output a different color.
if you plot the luminosity changes with fast pixel changes over a color clock, you will see very clearly why these colors are produced.
This is the main source of artifacts. There are others but they're due to tube physics, etc and are not linked to the computer.
The ability of a system to make artifact colors depends on two things:
- The speed of it's pixel clock vs. the speed of the NTSC color clock.
- The 'location' on the circle of the system's colors.
On an Atari 800 for example, if we make a black and white bitmap, in 320x200:
(0 = black, 1 = white, - = don't care)
0010 = green
0100 = blue
1100 = orange
0110 = light blue
1110 = nearly white
1111 = white
Now, to answer you question: can a machine be manipulated to do this?
Since the phenomenon is tied to the NTSC/PAL color systems, it is possible to do these artifact when:
- The machine outputs a composite color signal (a B&W signal doesn't have a color burst and the TV set will not enable color decoding).
- The pixel clock is a higher frequency than the color clock.
That means pretty much most retro-computers. Typically, the pixel clock will be an even multiple of the color clock, such as 7.16 MHz or 14.32 MHz. This holds true for the Apple ][, IBM CGA, Tandy Color Computer, and the Atari 8-bit, all of which are known to support artifact color modes. (See this link for pixel clock frequencies.)
Some systems had more flexibility with different modes (and different pixels rates), more base colors (allowing more combinations since they can start a block of pixels with different color phase shifts), but the effects can be clearly calculated.
It is to be noted that TVs all react a bit differently due to how they detect the phase change, but overall you wouldn't get that many variations.
I have implemented video hardware; this stuff is simple to explain on a white board, but a bit hard to convey in writing :D