Suppose you were, in the early eighties, designing a color computer to run on an NTSC TV with a free hand to choose the specifications within the limits of the technology of the time. What would be the ideal resolution?

NTSC has 262.5 scan lines, but not all are visible; for reliable full visibility on all TV sets, you don't want to go much over 200, so e.g. the Commodore 64 went for 200 and the Atari 800 for 192.

Horizontal resolution looks trickier. The color clock cycles 227.5 times per scan line, so that suggests horizontal resolution should be a bit less than that, maybe just over 200. On the other hand, the Commodore 64 did 320 and seemed okay. On the third hand, my experience with that was on PAL, which offers higher resolution and better color reproduction at the cost of lower frame rate. I don't know how good the color display was on NTSC. The relationship between the color clock and pixel resolution is, I gather, subtle, complicated and difficult to grasp for one not thoroughly versed in that art.

Do you actually get better results when you make the horizontal resolution exceed the NTSC color clock? If so, er, how is that possible? If not, does that mean it was pointless for the Commodore 64 to go 320?

For that matter, I remember looking up close at a TV screen (though PAL again) and seeing the pixels, each composed of three vertical stripes, red, green, blue. I would have thought the pixel resolution of the screen would be highly relevant in discussions like this, but it never seems to get mentioned. What am I missing?


The pixel clock doesn't have to be the same as the color clock. In fact, it's usually higher. Remember that in a composite video signal, the chrominance information (whose resolution depends upon the color clock) is less important than the luminance information (whose resolution depends upon the pixel clock), so the color clock can be (and usually is) slower than the pixel clock. Color information is actually subsampled, as in JPG files.

If I were to design a video mode with NTSC output in mind, I would start with the color clock, which for NTSC is 3.57 MHz (aprox.) As discussed, you can have the pixel clock to be faster. Ideally, an integral multiple of this color clock. This way, some interferences such as "crawling dot" are avoided. This particular interference is present when the color clock is not in phase with the pixel clock, and this happens when both clocks are not depended one each other. An ideal design should use a single clock to derive both pixel clock and color clock for the NTSC encoder.

At the time, 4xNTSC crystals (14.31818Mhz) were usual and cheap, so I would pick my pixel clock to be that value.

As you notice, NTSC vertical resolution is 262.5 scanlines. NTSC interlace signal is not a big deal, but most retro computers use the vertical retrace period to trigger an interrupt, and game developers (at the time) would prefer this interrupt to have always the same period (measured in scanlines, or CPU cycles).

So, I would design with a 262 scanline picture in mind, and using NTSC progressive scanning (always outputting the same field).

Of course, all the scanlines are not visible. A safe approach would be to take 240 visible scanlines, which is, not by chance, half the standard NTSC resolution, and center them on the screen. That would give us an upper and lower overscan area of (262-240)/2 = 11 scanlines. Some of these scanlines are actually part of the vertical blanking period, so I would except the number of scanlines at the bottom of the image to be less than the number at the top of it, if you want to keep the pixel addressable area centered.

This, in addition to the 4:3 aspect ratio, yields a horizontal resolution of 320 pixels, so my screen resolution would be 320x240 with a border, or overscan area that would cover the rest of the picture. The standard NTSC resolution is 640x480. It's not a surprise that many standard resolutions among different computers have numbers very related to this one. Commodore 64, for example, but also CGA, EGA and VGA. Remember that early CGA adapters had a composite video output RCA jack, besides the Sub D 9 RGB TTL connector.

OTOH, A 14.31818 MHz pixel clock gives us more than 900 pixels per scanline. Therefore, I would divide that clock (now our master clock) by two to get a pixel clock of 7.15909 MHz. A scanline in NTSC lasts 63.5 microseconds. Using this pixel clock, the entire scanline is divided into 454.6 equal time intervals. Of course, we cannot use fractional time intervals, so I would use 454 ticks (clock periods) per scanline, for a total scanline time of 63.416 microseconds, which is pretty close to 63.5 microseconds, required for NTSC.

So we have 454 ticks in a scanline. 320 of them will be used to display actual pixels, while the rest of them will be used for horizontal blanking period.

| improve this answer | |
  • 4
    When using a multiple or near multiple of chroma, repeated dot patterns are likely to cause false colors. On computers where horizontal sync and chroma are synchronous this can be useful (that's the way color is produced in Apple II high resolution modes, for example). In general, though, it's better if the rates not be near multiples. A rate of about 5/3 chroma will do a nice job of avoiding chroma artifacts while yielding roughly-square pixels. – supercat Jan 29 '17 at 17:05

If I were designing video hardware and wasn't wanting to exploit chroma aliasing, I'd probably use a dot rate of about 10/3 or maybe 3.5x chroma, which would yield pixels with a roughly 1:1 aspect ratio in interlaced modes, or 2:1 in non-interlaced modes. If it wasn't necessary to go out to the border, that would yield a nice power-of-two screen size (512 pixels) which could facilitate the design of graphics hardware and software.

If I wanted to facilitate the use of chroma aliasing, I would probably use 4x chroma as a dot rate and, if memory weren't critical, have 1024 logical pixels per screen row (leaving some storage unused at the end of each line). I'd make the horizontal rate programmable as 227.5 or 228 chroma clocks, and the vertical programmable as 262, 262.5, or 263. Using 228 chroma clocks per line would yield vertically-striped chroma pattern. Using 227.5 chroma clocks on 262 lines would yield a stationary checkerboard pattern. Using 227.5 chroma clocks on 263 lines would yield an alternating checkerboard pattern. The alternating pattern would allow a better-looking display if software was able to render different content on even and odd frames, but the stationary checkerboard would probably look better than stripes if software could either handle having different objects for even and odd scan lines or else limited motion to two-pixel increments.

| improve this answer | |
  • 4x chroma matches some documents I was able to find that suggest the luma frequency is 4x the chroma frequency, was that the motivation? Would suggest the ultimate horizontal resolution (leaving aside color) is 910; how does that square with the talk about nominal NTSC resolution being 640x480? – rwallace Jan 29 '17 at 18:39
  • 1
    @rwallace: There is no single luminance frequency; luminance can go anywhere up to about 4x chroma. The Apple II generates 16 lo-res colors by rotating through a 4 bit pattern at a rate of 4x chroma and hi-res colors by outputting alternating black and white pixels at 2x chroma; using one CPU clock every 7 pixels yields a speed of 1.0227MHz--within tolerance for a 1MHz 6502. The Atari 400/800 probably use 2x chroma for hi-res mode because the Atari 2600 used 1x chroma, and the 400/800 follow suit in medium-resolution mode. – supercat Jan 30 '17 at 15:22
  • 1
    @rwallace, if your luma resolution is 4x the chroma resolution, e.g. 14.318 MHz, you can generate NTSC colors just by using the luminance signal. For example, four adjacent pixel luminecities of 160,160,160,160 will be light grey. But if you add a little "ripple" on top of it 160,161,160,159 will be light yellow if it's in phase with similar ripple in your colorburst. But 159,160,161,160 will be light blue. Some computer graphics adapters such as CGA generated color a little this way, like supercat said. So if you want to generate color cheaply, use 4 x chroma pixel clock. Otherwise, don't – PkP Jun 29 '18 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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