Does every retrocomputer and console with NTSC composite output have 'artifact color' ability?

Question

Artifact color is heavily associated with the Apple ][, since that is the only method the machine had to produce a color display. I was looking at the fantastic demo for IBM PC + CGA, 8088MPH, and I vaguely understand how they managed 1K colors with CGA as in the screenshot.

For the 1K color mode, the ability of the CGA text mode to use the 16 direct palette colors is combined with the artifact color technique. Basically, 4 different 8-bit horizontal pixel patterns at a resolution of 640x200 each produce a 256 color palette by combining 16 direct colors x 16 artifact colors. When all 4 pixel patterns are used, you get a theoretical 256x4 unique colors on screen. See blog post for more details.

What surprised me was the ability to have far more than 16-colors on screen by "combining" the direct color output with the artifact output to get a whole slew of 16-color palettes all available at once. I thought that real composite color output and artifact color output were somehow mutually exclusive.

So, is there any case where a retro machine equipped with NTSC composite color video output can't be manipulated to create some "high-color" modes like this? Can you provide other examples of this technique for other retro machines and consoles, especially those which were never advertised to have an artifact colors mode?

This seems especially relevant for games, since artifact color modes don't carry any (much) CPU burden to display.

Answer 1

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

Answer 2

Colour in NTSC is represented as the high-frequency part of the signal. A colour-aware TV will separate the low and high frequency parts. The colour decided will depend on the relative phase of the colour signal and the colour burst, a brief period of pure signal from the retrace period.

Therefore the ability for a computer to affect colour decoding depends on (i) having a high enough frequency output; and (ii) having a known or programmable colour burst relative to which the adjustable pixels are at a predictable phase.

You can't do colour on the Timex, or probably some other monochrome computers, because they don't output a colour burst. Neither does the Apple in its text mode — a deliberate choice to allow high-resolution text without it turning into noisy colours. So a conformant TV won't try to decode colour at all.

You can't do the style of colour artefact you're asking about on an Atari 2600 because the output clock isn't fast enough. The fastest it ever outputs pixels is exactly one per colour cycle. Though the way that one colour blends into an adjacent colour is another kind of NTSC colour artefact.

I can't claim to have knowledge of how everything else aligns pixel output and the colour burst but most computers are probably aligned just because NTSC colour clock oscillators were cheap and widely available due to their use in TVs. You even see PAL micros such as the ZX Spectrum just because of availability and because they're the good side of the 4Mhz rated limit of a Z80.

Output frequency with a colour-burst are therefore the two main things to look for.

Answer 3

Let's sort out some different kind of color artifacts.

1) The composite signal carries both lumincance and chrominance, the latter encoded in the phase of the color carrier. That means if it's somehow possible to change the composite signal quickly enough, it will affect the color.

This is not a consequence of the bandwidth limitation of luma and chroma (which is the natural result of the way they are mixed into one signal): if you'd somehow transport luma and chroma seperately as three signals to the monitor, and bandwidth limit them in the same way as the composite signal, you'd see none of those artifacts.

Some computers use this effect by design: In the Apple II Hires mode, the pixel dot rate is twice the color frequency, so an alternating pixel pattern 010101 corresponds to one color (depending on phase and an additional mechanism to adjust phase). In the Apple IIe Double Hires mode, 4 pixels correspond to one color cycle, so again this bit pattern determines the color. In the CGA Graphics, combining different colors in a pattern creates a mix of phases that is decoded as a new color, as can be seen in this youtube video.

Some computers are not designed to use this effect, e.g. the Commodore 64.

In some instances, with a bit of cleverness and modern means of producing cycle-counted code, it's possible to cause even more artifacts than intended (or not intended). This is how the 8088 MPH demo does the additional colors. In principle, one can do that on any system where you can repogram the video circuitry while the image is produced. However, it's quite difficult to make it useful: You need to reprogram at exactly the right time in exactly the right way, and you need to be able to do this fast enough and in some way that still produces a sensible image with the new colors.

For example, it's next to impossible to pull this off on the Apple II without custom hardware modifications, because sync timing information is not available, and the only thing you can change is the framebuffer. It might be possible to do something like that on the Apple IIe (toggle MSB at exactly the right time), but it would be damned difficult to do, and I haven't seen it. I don't think it can be done on the Commodore 64, because as far as I know one cannot reprogram the VIC in a way that produces meaningful changes in the color carrier phase, but who knows, maybe someone finds a way.

To sum up: Some computers are designed for to use these kind of artifacts, some are not. In principle, one can attempt to create these kinds of artifacts on any system, but it's difficult to get useful results.

But there are other kinds of color artifacts:

2) On analog TVs, the color of adjacent lines usually blended into a combined color (everything was a bit blurry, anyway). That's an effect you could use on all platforms, and that's why you'll often see patterns using two alternating lines for larger colored areas in games.

This effect is due to the way the human eye recognizes colors and the physical properties of the phosphorous in the TV screen.

3) A similar effect, but using a temporal instead of a spatial mechanism, is to change the color very quickly (every frame). Then again, both colors will blend together and produce a new color. For the e.g. the Commodore 64, the effect is explained here. I don't think this effect has been used frequently.

Answer 4

I think these are the necessary features:

1. Color burst, or the ability to 'draw' before the left border
2. Pixel rate higher than the colour clock, possibly a multiple and in phase
3. No low pass filters on the composite output

Here some data I collected for various home computers:

Amiga: can do NTSC artifacts. The machine already had plenty of colors therefore the technique was not exploited. Plus, most of the users had RGB monitors. A possible exception is virtual karting 2.

Atari 8 bit: possible. See here.

C64: the dot clock is not a multiple of the color clock. It is around 8.18Mhz for NTSC. This means that NTSC artifacts are visible using hires gfx but they will vary across the scanline and time, not usable. Other artifacts are were commonly used instead. Flickering and PAL delay line mixing.

ZX spectrum: pixel clock is 3.5 mhz, not a multiple if the color clock. Only the ZX spectrum 128 had same clock for color and pixels. Indeed this mini game proves it can do color artifacts.

Zx81: it generates a color burst https://baltazarstudios.com/sinclair-zx81-lives-on/ but the dot clock is related to the 3.25 MHz CPU clock.

Amstrad Cpc: the dot clock is 1mhz multiple therefore artifacts are not usable. It is an RGB machine.

Answer 5

For NTSC artifacting to be most useful(*), the dot clock must be a multiple of chroma clock; on all such systems I know of where it's useful, it's either 2x or 4x.

Further, for purposes of artifacting, there are four different ways that systems can handle horizontal and vertical timing:

1. Horizontal = chroma/228; vertical = anything near 262

2. Horizontal = chroma/227.5; vertical = horizontal/262

3. Horizontal = chroma/227.5; vertical = horizontal/263

4. Horizontal = chroma/227.5; vertical = horizontal/262.5

Broadcast video standards only allow for #4, but television sets' electronics have enough tolerance to accept any of the above (most sets should easily tolerate 260-264 without recalibration, and will either accept a wider range directly or will include a "vertical hold" knob that can be adjusted for a wider range).

On systems that use the first style, a solid color area should be drawn as a pattern of vertical stripes. On those that use the second style, they should be drawn as a stationary checkerboard, but I've only seen that on karaoke CD+G displays and I don't know if they're consistent enough to make aliasing usable. On a system that uses the third style, a solid color should appear as a checkerboard that reverses phase every frame, and one that uses the fourth style (interlaced video) would require cycling through a four-field pattern. I think there's a digital video standard that outputs pixels at 4x chroma and relies upon artifacting for color; there's also another standard for digital component video which uses 3.5x chroma (a frequency which minimizes artifacting).

The Commodore VIC-20, 64, and 128, and the Apple II all derive their system clock by using a frequency that's 2x chroma and dividing by 7. The VIC-20 then multiplies that by 4 to get the pixel clock, and the C64/128 multiply by 8. The Apple II adds an extra half-chroma period to the system clock every scan line to yield a line rate of chroma/228, while the VIC-20 and most Commodore 64s divide the system clock by 65 to yield a line rate of 227.5. My first Commodore 64 used a line rate that was an integer submultiple of chroma (so color areas appeared as stripes) and I remember having determined that the horizontal rate was CPU clock/64 (which would yield a line rate of chroma/224), but that video chip was wonky in other ways (two sprites couldn't show single-pixel-wide areas very well) so I replaced it and junked the original. I've never heard of any emulators supporting a horizontal rate of sysclock/64, so I wonder if my chip was broken in unique fashion.

(*) On the Ninteno Famicon/NES, the pixel clock is 1.5x chroma and thus its period is 2/3 of a chroma clock, so every three pixels will map to two chroma clocks, and scan line chroma phase is staggered by 1/3 chroma clock (half a pixel, or a chroma clock minus one pixel). Color artifacting doesn't work as well as on systems which use 2x or 4x chroma, but is still somewhat effective.