Ideal resolution for color computer on PAL/SECAM

Question

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

While similar a question as in the case of NTSC, PAL has multiple variants and a sibling system named SECAM to be compatible of, and of course a higher resolution.

Link:

• Ideal resolution for color computer on NTSC
• NTSC scan lines and vertical resolution

PS: Since in character mode the color changes less often (say 8 time less than theoretical resolution), does that mean Text mode allows higher resolution regardless of video memory cost restraint?

Answer 1

In the early 80s, cost of RAM for the framebuffer was the dominant factor, closely followed by RAM bandwidth. The difference in resolution between NTSC and PAL systems is minimal in comparison to these factors (note that despite the different number of lines per field and different field rate, each technology used a very similar line rate of ~64us per line, thus with any given technology the limits of its horizontal resolution will be similar).

Another limitng factor is that the larger the framebuffer, the longer it will take to update it, thus a smaller framebuffer will often be more useful than a large one.

A few years ago I started collecting ideas for designing the best possible 8-bit machine that could have been built with a realistic budget in 1981. I did some analysis of available time with the fastest economical DRAM and a Z80B, and determined that 360 pixels with 16 colours was the highest realistic resolution without reducing the processor's speed during screen refreshes. This could be paired realistically to either a 240P or 480I vertical resolution, but the latter would like require too much memory to be realistic.

Answer 2

What would be the ideal resolution?

There is no "ideal" resolution. TV screens use "overscan", which means that the full TV image is occluded by a bezel. That doesn't matter for movies, but it does matter if you have text on the screen. So you need to choose a part of the image that would be inside the bezel of most TV models, because the size of the bezel varies.

Both PAL and NTSC have a fixed number of lines (and are interlaced, but let's leave this aside). So you pick a number of lines close to what you have identified as the always visible part.

Horizontally, it's all analog. There are no "pixels", you are free to choose whatever resolution you want. However, you have a central clock in your computer, and you want your pixel clock to be something that has a relationship to that clock. You also have to keep in mind that access to RAM needs time, and access to RAM must be shared with the CPU. So from that constraint you derive some horizontal resolution that fits your timing, and that goes together with the vertical resolution so you can fit the framebuffer in some power of two.

And this complicated process is why every home computer had its own resolution (or resolutions).

---

As some interpretations of the original question seem to aim at the maximal resolution, let me rephrase the question to "if there are no technology constraints, how would you implement display on the TV?". And while this may be in reach with 80s technology, it would be a stretch, in particular in the early 80s. But anyhow:

• Use the full screen resolution: interlaced, all lines vertically, and some kind of Y4U2V2-like approach for the framebuffer, so intensity resolution is higher than color resolution.
• Have some way to handle text so text can be scaled, anti-aliased, and have sharp transitions. That will require more internal horizontal framebuffer resolution than it's possible to display due to color-carrier bandwidth restrictions (or RF restrictions), and probably additional filters.
• Require all software to put meaningful text only inside a user-adjustable area (while "unimportant" graphics near the outside can be hidden by the bezel, just like for movies), and scaled as above, and require software to handle the variable text resolution.

In that way, one could come really close to an optimal usage of all the TV can display. (But of course, for the cost of thus effort one could just buy a monitor, and use that instead of the TV ...)

Answer 3

If this is about connecting the color computer to television antenna input via an RF modulator, then the local TV system variant matters, as both the RF modulator for the computer and the RF demodulator in the TV are built to use a certain composite video signal bandwidth.

For a 625-line 50 Hz field rate TV system, the maximum composite video signal bandwidth ever used with PAL or SECAM color encoding over RF is 6 MHz.

As the line rate of a 625/50 TV system is 15625 Hz, it means that 384 cycles of 6 MHz sine wave fits into one line. As one cycle of sine wave means basically a white pixel and a black pixel, there are 768 total pixels per line, with a pixel clock of 12 MHz. Since the active video portion of a line is 52us out of the 64us, there are 624 active pixels, of which not all are even visible due to the TV image being slightly overscanned.

In practice, if direct composite video connection is used, the RF modulation and demodulation are not present to artificially limit the bandwidth to 6 MHz.

Basically this means that the situation is similar than between equipment in a TV studio, the transmitting device like a camera can use as much as bandwidth as it can and the receiving device can use as much bandwidth as it possibly can. There is a good chance that consumer TV equipment can have similar bandwidth limitations on the composite input than on the RF input, but it can also accept higher bandwidth.

There is not much use going past 6 MHz though, as even the BT.601 standard digital component video used in studios does not use analogue bandwidth much past 6 MHz, but it samples the PAL and SECAM signals at 13.5 MHz to arrive at 702 active pixels for the analogue portion of the line, so that sets the point of having overkill resolution.

So having said that, I would estimate that due to 5% of overscan per side, and the requirement to fit text well inside the edges of a TV, the usable area would be maybe 90% of the 624 pixels or 562 pixels tops. In worst case if you lived in a country with a 5 MHz TV system with bandwidth for 520 pixels, maybe less than 470 pixels per line via the RF modulator. With direct composite video connection, maybe 640 usable pixels per line is achievable as a practical maximum, but it can already be blurry and sharp edges will have fringe colors. 640 pixels would achieve 80 colums with a font of 8 pixels wide.

For vertical resolution, the PAL signal has 576 active lines when interlaced, or 288 active lines per field. Accounting for the overscan, there would be about 256 lines visible per field, or 512 lines per interlaced frame.

So through this thought process, I ended up with a resolution of 640x512 as the resolution that is the approximate maximum that can still be presented on a TV without too much blurring.

If we compare this to for example an Amiga 1000 which was designed in the early 80s, it also happens to use 640x512 as the hi-res mode. It also allows individually to halve the horizontal resolution by two to have a lo-res mode with 320 pixels per line, and it also allows turning off the interlacing to have a progressive mode with 256 lines per frame.

In real life, it is a bit more complex than that, since while the composite video signal can have bandwidth up to 6 MHz, it only applies to the monochrome brightness signal, the color resolution is much less as it only has a bandwidth of 1.3 MHz.

Answer 4

I'll take PAL to mean the specific composite-video signal format for color TV, deliberately excluding higher-resolution versions like S-video with multiple signal lines (see Wikipedia).

The vertical resolution is fixed by the signal timing of 625 interlaced scan lines, meaning that you can either use interlacing and get a maximum of 576 lines with a very annoying 25Hz flickering or 288 lines with 50Hz.

For the horizontal resolution, if you're mainly interested in brightness reproduction (accepting that you'll only be able to give two adjacent pixels different brightnesses, with badly blurred color differences), then the PAL luminance bandwith of roughly 3.5 MHz within the available active scan line time of 52µs is the limiting factor, meaning that you might get 3.5 * 2 * 52 = 364 pixels onto a single line. Compared with the 288 vertical resolution, this comes close to the 4:3 screen aspect ratio, giving you square pixels. For an "exact" 4:3 ratio, you'd push the horizontal resolution up to 384.

The color resolution will be much lower, limited by the bandwidth of the chroma signal (roughly 1.3MHz), giving you 135 effective pixels. Such a low resolution, combined with the very non-square pixels, doesn't make much sense, so you'd typically go for the brightness-based calculation, accepting the blurry colors.

In addition to these signal parameters, we have to look at the TV sets, typically being adjusted in such a way that the full (rounded-shape) screen gets video signal without black borders around the picture, meaning that especially in the corners, video signal gets lost "outside of the screen". So, instead of 384x288, you'd choose something like 320x240.

Then there's the question of budget. If you go for a dedicated video RAM, then 320x240 gives 76800 pixels, just beyond 2**16 (=65536), meaning that you'd have to go for the next bigger DRAM chips, but wasting 40% of their capacity. So, maybe you'd reduce the resolution to stay below that threshold. If you share the RAM between video and CPU, then this argument doesn't apply, as every single byte not used for video will be available for your application programs.

Answer 5

PAL's (and NTSC's) main technical limitation is its number of scan lines. In theory, you have 625 lines to work with, but interlacing means that you'll probably want each pixel to be at least two lines high so that it's (partially) present on the screen at all times. And if you also figure that the top 10% and bottom 10% of the screen are off-limits as a non-“title-safe” area, that leaves you with a maximum vertical resolution of 250 lines.

Other than that, it depends mainly on your video RAM budget. For the sake of having a concrete number to work with, I'll assume you can afford 16 KB, matching the Commodore 64, or the original IBM CGA graphics card.

Your screen resolution must satisfy vhc ≤ m, where:

• v is the vertical resolution (number of lines)
• h is the horizontal resolution (number of columns)
• c is the color depth, in bits (allowing a maximum of 2^c simultaneous colors)
• m is the available framebuffer memory, in bits

Alternatively, this can be expressed as v²ac ≤ m, where a=h/v is the aspect ratio. For given values of a, c, and m, then v ≤ √(m/(ac)).

So let's plug in some reasonable values for aspect ratio and color depth, given the aforementioned constraint of m=131072 (bits, not bytes).

• a = 4/3, c = 1 → v ≤ 313
• a = 4/3, c = 2 → v ≤ 221
• a = 4/3, c = 4 → v ≤ 156
• a = 4/3, c = 8 → v ≤ 110
• a = 4/3, c = 16 → v ≤ 78
• a = 3/2, c = 1 → v ≤ 295
• a = 3/2, c = 2 → v ≤ 209
• a = 3/2, c = 4 → v ≤ 147
• a = 3/2, c = 8 → v ≤ 104
• a = 3/2, c = 16 → v ≤ 73
• a = 8/5, c = 1, → v ≤ 286
• a = 8/5, c = 2 → v ≤ 202
• a = 8/5, c = 4 → v ≤ 143
• a = 8/5, c = 8 → v ≤ 101
• a = 8/5, c = 16 → v ≤ 71
• a = 5/3, c = 1, → v ≤ 280
• a = 5/3, c = 2, → v ≤ 198
• a = 5/3, c = 4, → v ≤ 140
• a = 5/3, c = 8, → v ≤ 99
• a = 5/3, c = 16, → v ≤ 70
• a = 16/9, c = 1, → v ≤ 271
• a = 16/9, c = 2, → v ≤ 192
• a = 16/9, c = 4, → v ≤ 135
• a = 16/9, c = 8, → v ≤ 96
• a = 16/9, c = 16, → v ≤ 67

The 16-bit color modes would have miserably small resolution, around 100×70 or so (depending on the aspect ratio). So probably not worthwhile to implement.

OTOH, the 1-bit “color” modes give about 300 lines of vertical resolution, which as previously stated is more than a TV set can support. Besides, having a monochrome display hardly qualifies as a “color” computer, even if you provide the ability to select the foreground and background colors.

So, the reasonable values for color depth are 2-8 bits. Of course, it was commonplace to give programmers multiple graphics modes to chose from. So, for example, if you want a 4:3 aspect ratio, you could have:

• A monochrome mode with 320×240 px resolution, using 9600 bytes of memory. (Resolution limited by TV display.)
• A text mode with 30 lines of 40 columns each, equivalent to breaking the monochrome mode into 8×8 character cells. Uses only 1200 bytes of memory. You might as well even add an extra byte for each character cell to indicate a 4-bit foreground and background color.
• A 2-bit (4-color) mode with 288×216 px resolution.
• A 4-bit (16-color) mode with 192×144 px resolution.
• An 8-bit (256-color) mode with 128×96 px resolution.

With the numbers rounded down to allow the resolutions to be multiples of 8×8.

Answer 6

One of the design points for the BBC Micro was that it should be usable by the BBC itself as a low-cost broadcast image generator and Teletext editing device. The BBC, of course, broadcast on the PAL standard. This probably influenced the choice of resolutions, which use nearly all of the "safely visible" area of a typical TV.

The highest resolution the BBC Micro supports is 640x256 (MODE 0), but it only has enough RAM to display that as a 1-bpp image. The 640 horizontal pixels actually exceed the resolvable resolution of a TV, but this capability gave the machine a good 80-column text mode and a crude form of antialiasing. For more colours or less RAM usage, 320x256 (MODEs 1 and 4) and 160x256 (MODEs 2 and 5) are also available.

All of these are based around the 2MHz CPU cycle, derived from a 16MHz master clock which is also the pixel clock for MODE 0. The 64µs horizontal scan rate allows for 64 or 128 byte fetches to be interleaved with the CPU cycles, of which 40 or 80 occur during the "active" interval and are translated into 2, 4 or 8 pixels each. The rest are still fetched by the CRTC and used as a DRAM refresh mechanism, but the conversion to pixels is suppressed during the blanking intervals.

PAL is an interleaved format, with up to 288 image lines per field at 50 fields per second. The BBC Micro simply outputs the same image during both fields of a frame. With more RAM, it would be feasible to output different images in each field, producing an interlaced image with up to 576 lines, although some of these would disappear off the top and bottom of the screen. A 640x512 resolution would be a logical upgrade to fit within the "safe" area. Due to interlace effects and the limited horizontal resolution, objects should be made at least 2 pixels thick in both directions to be clearly visible without flicker.

The full resolution of PAL, including the overscan areas, is generally taken as 720x576 interlaced; video captures are often based on this. Using this full overscan size for graphics can be useful for applications where having a hard, visible border is distracting - such as game consoles that want to show a scrolling playfield - as long as any important information is kept in the "safe" central 640x512 area.