Ideal resolution for color computer on NTSC

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

F=14.31818MHz was a common Crystal. I have a fistfull from Halted in Sunnyvale, CA which regrettably is now System Halted. F/2=7.15909MHz F/4=3.579545Mhz (<-- That is the Color Burst frequency). 14.31818Mhz is also the master clock frequency in the Apple ][ and probably lots of other computers. It drives the video counter part which generates H and V Sync as well as color burst and generates address to read video memory and its really neat to.

Apple had wide horizontal borders so 280 pixel wide while many other computers were 320 pixels with smaller boarders but still some space for another ~40ish maybe hmm pixels. The pixel size is fixed in Color mode(Any line with Color Burst). In B&W mode when there is no colorburst Horizontal resolution is --->infinite... or much higher depending how sharp your B&W tv/monitor is.

Apple was weird in that each video BYTE encoded 7 not 8 pixels. That didn't change no matter text, lo-res or high res. Hi Res each byte 7 pixels and high order bit shifts pixels (half a pixel) in effect selecting different 2-color + B and W pallet. Lo res graphics just used upper or lower nibble 4 bits and double color burst freq which TV interpreted as a color. Apple really had no TV color hardware except video bits and horizontal and vertical sync going into ONE TRANSISTOR with a few resistors to get correct voltages.

None of these late 70s early 80s computers thought to have two displays driven by a-lot of the same circuitry(So very minimal increase in price). B&W for high resolution such as 80 column text on an el cheapo TV or monitor and low resolution color on a TV or monitor. How about triple ended.. Could of had an 8-bit DAC behind an Analog MUX(As in Vectrex) driving X and Y of XY o'scope (maybe brightness too) for vector graphics. Probably would of needed dedicated CPU for that.

Color information was encoded in some super weird thing called Quadrature modulation. So instead of just transmitting brightness a F/4=3.579545Mhz sine wave is added to that and shifting that wave a-little ahead or behind encodes one color and adjusting that waves amplitude (or I think half wave pattern) encodes another color and the general amplitude of everything is brightness. Sooo complicated who came up with that!? Why not have a color burst and then send RGBRGBRGBRGBRGB.... That would be backwards compatible with B&W TVs so a color picture would look a-little grainy if u looked close to the screen. That would leave the possibility in the future of doing RrGgBb to double horizontal resolution when electronics got good enough.

If you have a monitor or TV with RGB input you can trick it to actually see the F/4=3.579545Mhz wave. Plugging the YELLOW composite signal which has that color burst frequency wave into one of the RGB depending which kind of RGB it is will make it think that is only the amplitude so you can see the grainy colorburst frequency on an HDTV or high res monitor.

Since TV was interlaced why didn't somebody back in the 60s do 3D TV? You could wear a mask with a disk in front of you face rotating at 60Hz.. oops I mean 30Hz. There could be a signal from the TV keeping the disk in sync with the TV. Half the disk would be transparent and the other half opaque so the result would be one eye would see the even lines and the other would see the odd lines so interlaced TVs could of had 3D broadcasts sometimes. That would of been so much fun!!

This manual has a good section on NTSC. I guess to really understand it you need to write code with a high enough speed DAC and drive the entire NTSC signal yourself. I made an Apple II in an FPGA and noticed B&W monitors are very forgiving about having the voltages far off the color composite inputs are more picky. Your clock generator needs to be configurable enough to get close to color burst frequency otherwise the TINT or colors will shift across the horizontal scan line.

The Apple II circuit description Paperback – January 1, 1983 by Winston Gayler (Author) has a good section on NTSC.

Does this video link to my Xilinx FPGA Apple II work? https://media.mewe.com/a533e2ad-c5cc-41b3-8b5f-7209ca136a3b/720p.mp4?Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHBzOi8vbWVkaWEubWV3ZS5jb20vYTUzM2UyYWQtYzVjYy00MWIzLThiNWYtNzIwOWNhMTM2YTNiLzcyMHAubXA0IiwiQ29uZGl0aW9uIjp7IkRhdGVMZXNzVGhhbiI6eyJBV1M6RXBvY2hUaW1lIjoxNjEzODEzMDIyfSwiSXBBZGRyZXNzIjp7IkFXUzpTb3VyY2VJcCI6IjczLjE4OS4yMjAuMjIvMzIifSwiRGF0ZUdyZWF0ZXJUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjB9fX1dfQ__&Signature=e02xjXRbTPqFIB4CvZBkLB1Cgxari-RlYbur0fbfC1NG7GNzLkHQV9exusONr7bAl96-WMb336TncduiCSjEG-69eODkABqXeUcvOt3lASBiD6ShLTM~ej-5lWJQBCpo1830YyfITQrJw2yDFvTQf2NavewxDhUpYnBo5uH4l6w_&Key-Pair-Id=APKAJ27JL4J435IAPVQQ

A few posts down my MEWE page you can see my Apple II FPGA and hear me breathing so turn the volume off unless you like Darth Vader. https://mewe.com/i/frederickkilner

May The Force Be With You -ME