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.

Multicoloured 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.

  • 4
    It’s worth linking to Andrew Jenner’s explanation of the 1024 colour technique for more background information (and just general curiosity since it uses pretty much every CGA trick known so far and invents a few more). – Stephen Kitt Apr 3 '17 at 5:05
  • You should keep in mind that the 'artefact color capability' is based mostly on how analog TVs handle color (it's encoded as the phase of the color carrier frequency), how the analog TV screen works (phosphor), and how the human eye perceives these things as color, even if changing spatially or intime. So to some degree, everything that uses an analog TV can produce such artefacts. To what degree, and to what degree these surpass the "in-built" color ability, depends heavily on the system. – dirkt Apr 3 '17 at 5:59
  • 1
    Do you mean "with colour NTSC output"? – wizzwizz4 Apr 3 '17 at 10:25
  • @wizzwizz4 My assumption is that 'composite video' implies color. I suppose that the combination of mono and sync could also be referred to as 'composite video', but not for this question. – Brian H Apr 3 '17 at 15:04
  • @BrianH that's actually exactly what Acorn thought it meant; its machines — such as the Electron — with a composite RCA output use it for monochrome video (though the boards were designed to allow easy modification to composite colour). Colour is available on an unmodified machine only via RF or the RGB monitor port. But, yeah, not what's meant by this question. – Tommy Apr 3 '17 at 15:30
up vote 16 down vote accepted

In composite video, a scanline has the following format:

Scanline

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:

NTSC Colors

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

  • 1
    Great explanation. Do I spot a typo where you say "pixel clock is NOT an exact multiple of the color clock"? – Brian H Apr 10 '17 at 16:00
  • thanks! this is correct: in NTSC there is roughly 228 color cycles per scanline (including the blank, etc). A lot of computers at the time had an horizontal resolution of 160 (+blank, etc) so that a pixel would last exactly one color clock, allowing for a clean pixel with the right color. Obviously pixels that would be 2x, 3x, 4x, etc the color clock would work fine since they'd overlap with a full color clock. The problem is when a pixel gets smaller than a full color cycle (or if they're offset, which happened with clock drift as temperature changes on some systems; I think the atari 7800). – Thomas Apr 10 '17 at 16:23
  • 1
    But most systems that support artifact color seem to have dot clocks that are 1/2 or 1/4 the period of the color clock. Or, dot clock is 2x or 4x the color clock, as an exact multiple. 7.16 MHz dot clock is most prevalent. – Brian H Apr 10 '17 at 19:21
  • @BrianH, I believe the key for generating artifact colors is that the luminosity changes inside a color clock cycle. A pixel that is two color cycles long can't generate artifact colors, but one that is 3/2 cycles long can generate artifact colors on every other color cycle, and a pixel that is 1/2 cycle long can generate artifacts on every cycle. – Mark Apr 10 '17 at 20:23
  • 1
    @Mark Then shouldn't the answer say "The pixel clock is greater than the color clock". An exact multiple (2X, 4X) IS the norm for machines that support artifact color, so exact multiples CAN'T be excluded in the answer. – Brian H Apr 10 '17 at 21:56

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.

  • It sounds like you are saying that any retro machine with composite color (NTSC) output and some minimum horizontal resolution can do artifact color modes. Depending on what is the minimum resolution (obviously, higher than an Atari 2600), that could imply a lot of retro machines. – Brian H Apr 3 '17 at 18:18
  • @BrianH I can conceive of at least one other scenario in which they wouldn't be able to: if the generated scan line really were 227.5 colour cycles long as it's meant to be, rather than the 228 most micros assumed to be within tolerance, so where pixel n is relative to the colour phase depends on which line it's on, and the total number of lines generated were odd, so where pixel n is relative to the colour phase depends on line plus frame, and the machine underneath didn't have time to rewrite the entire frame buffer every frame. – Tommy Apr 3 '17 at 18:22

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.

  • 1
    For some bizarre reason, some Twilight Zone DVDs, viewed through a component video connection, show color artifacts in places where a scene contains a texture that would generate a frequency close to chroma. Nothing about the way the DVD is encoded or sent to the screen should cause artifacting, and the masters should be on either black and white film or a black and white video tape format with no chroma subcarrier, but somehow something on the process introduced NTSC chroma artifacts. – supercat Apr 12 '17 at 17:01
  • @supercat What's your source on that? – echristopherson Sep 14 '17 at 22:04
  • @echristopherson: What's my source on what? I've seen the chroma artifacts. Both DVD and component video separate out luminance from two chroma channels, with the latter two channels both being blank for a black and white image. I suppose the six Twilight Zone episodes that were mastered to video could have used color video tape format, since color videotape was invented in 1958 and they were recorded in 1961, but that would seem really unlikely. – supercat Sep 14 '17 at 22:14
  • @supercat Oh, OK. I was just asking if you read that somewhere or had personal experience. – echristopherson Sep 15 '17 at 3:58

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.

  • This answer would be more convincing with some examples. Take a common machine with composite output - the C64 - which attribute is it lacking that prevents it using the artifact color technique to gain a broader palette? – Brian H Apr 4 '17 at 15:14
  • @BrianH added examples. – Valentino Miazzo Apr 7 '17 at 6:54
  • This link has a good list of dot clock freqs for NTSC systems: pineight.com/mw/index.php?title=Dot_clock_rates – Brian H Apr 7 '17 at 15:49
  • Cool, fixed c64 dot clock. – Valentino Miazzo Apr 7 '17 at 20:45
  • On NTSC Commodore computers and the Apple II, the system clock is derived by dividing a 2x-chroma clock by 7. The VIC-20 and C64 then multiply that frequency by 4 or 8, respectively, to generate a dot clock. – supercat Apr 12 '17 at 15:45

For NTSC artifacting to be useful, the dot clock must be a multiple of chroma clock; on all 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.

  • Nice answer. Given the slight disparity between the answers provided, it would be nice to have a definitive reason why "the dot clock must be a multiple of the color clock" for artifact color to be useful. – Brian H Apr 12 '17 at 16:43
  • 1
    @BrianH: On a system with consistent line-to-line color phase, but a dot rate that isn't a multiple of chroma (e.g. my old C64) showing one alternating black and white pattern on the first 8 scan lines and the opposite pattern on the next 8 would cause the first 8 scan lines to show a rainbow pattern that repeats every 16 pixels, and the next 8 to show a similar pattern, but the lower one would show blue when the one above was showing yellow, red when the one above was showing green, etc. – supercat Apr 12 '17 at 16:50
  • @BrianH: Basically, the big problem is that unless the dot rate is a multiple of chroma, the set of colors that can be generated is going to vary throughout the screen. A secondary difficulty is that on systems that aren't designed to facilitate color artifacting, adjacent scan lines and in many cases adjacent frames will have opposite color phase. I think the Apple II might have been nicer if it had used 227.5 chroma per line rather than 228. That would have required that software draw a checkerboard rather than stripes when wanting to display solid color, but... – supercat Apr 12 '17 at 16:54
  • ...I don't think that would have been overly difficult. It would, however, have made a lot of displays look a fair bit nicer. Having the chroma phase alternate each frame would have static images look nicer still, but at the expense of requiring that software render even- and odd-field images--something that wouldn't be practical in most cases. – supercat Apr 12 '17 at 16:55

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.