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.

Resolution chart


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?

  • 1
    Just to clarify, do you limit this to composite video only, so S-Video or RGB is not allowed?
    – Justme
    Commented Apr 2, 2021 at 9:34

6 Answers 6


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.

  • 1
    For most applications of that era, there would not be a frame buffer. Each scan line would be rendered individually, as it is needed, so no more than one or two lines ever needs to be held in memory. The question mentions character mode, which would never use a frame buffer.
    – Robyn
    Commented Apr 2, 2021 at 20:10
  • In character mode a machine might render directly to screen from the character buffer (1 byte per character) and the font buffer (fixed size regardless of screen resolution) with no frame buffer. A 40 column, 24 row character buffer is a little bit less than 1k plus however big the font buffer is.
    – Robyn
    Commented Apr 3, 2021 at 4:01
  • You might take a look at the DAI computer from 1980. It had remarkable graphics capabilities for its time. It overcame the bandwidth problem by interfacing the graphic chip to a 16 bit memory bus. The CPU accessed it with its 8 bit bus odd and even addresses. only the upper half of memory had this arrangement, so the CPU had full speed access for the lower half. en.wikipedia.org/wiki/… Commented Apr 6, 2021 at 8:53

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

  • 1
    «There are no "pixels"» — doesn't the shadow mask effectively create subpixels?
    – Ruslan
    Commented Apr 2, 2021 at 18:29
  • 4
    @Ruslan Yes, sort of, just not in the same way than you think modern subpixels. The electron beam is not infinitesimally small point, or a sharp large spot, but it is a relatively large to cover many "subpixels" or color dots and it has a gaussian shape, so a scan line would be brighter on the center and dimmer and softer above and below the edge. The spot area is large enough to cover many color dots to average the color out. Thus the subpixels cannot be controlled like on a TFT display. And a scan line from an analogue TV camera is analogue, there are no sampled pixels.
    – Justme
    Commented Apr 2, 2021 at 18:54
  • 1
    There is the title safe area that is guaranteed to be far enough from the bezels that text displayed there is legible, the area that computers actually use is somewhere in there, typically centered. Commented Apr 2, 2021 at 20:14
  • 1
    @SimonRichter: What's bizarre is that the concept of "title safe area" remains important today, since even when using HDMI different sets crop images by different amounts.
    – supercat
    Commented Apr 5, 2021 at 19:02
  • 2
    @Mavrik: Horizontal resolution was chosen based upon what dot clock rates would be convenient to work with. The Apple II, VIC-20, and Commodore 64 all fetch display bytes at a rate use 2/7 of the chroma frequency, while the Atari 800 family of machines uses chroma/2, and the Nintendo Entertainment System uses 2/3 chroma. All of those machines then use a dot clock which is a multiple of the rate at which display bytes are fetched: 7x for Apple, 4x for VIC-20, 8x for Commodore 64, and 2x for Atari (in color modes) and NES.
    – supercat
    Commented Apr 5, 2021 at 22:48

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.

  • ”If we compare this to for example an Amiga 1200 which was designed in the early 80s, it also happens to use 640x512 as the hi-res mode.” The original Amiga 1000 could be a better comparison here as it was actually designed in the early 80s and tops out at a 70ns pixel clock (the “high-res” mode). The A1200, released in 1992, shares much of its design philosophy with the original A1000 (as do all Amigas) but includes e.g. the somewhat impractical “super high-res” mode with a 35ns pixel clock (extremely narrow pixels for a standard-definition CRT TV or even typical 15kHz RGB/video monitors.)
    – Jukka Aho
    Commented Apr 5, 2021 at 18:16
  • 1
    @JukkaAho good point again - I did mean to compare with the original Amiga 1000 which was released in the 80s, not later models.
    – Justme
    Commented Apr 5, 2021 at 18:29
  • As an A1200 owner who has always used the PAL composite video output to a TV (CRT in the old days, now an LED TV) I agree with your analysis. Commented Apr 6, 2021 at 4:40

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.

  • If one were using 12 or 24 bits per pixel, 320x240 would be a nice resolution for purposes of power-of-two memory size, since one could clock out 960 nybbles or bytes per scan line and then group them into threes.
    – supercat
    Commented Apr 2, 2021 at 20:20

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.

  • The 13.5 MHz sampling standard of analog component video with 720 active digital pixels already includes more than the active analog video, the 52us of the active line is defined to fit to the center 702 pixels, often rounded up to 704 to be divisible by 8. An Amiga 1000 would fit about 738 pixels into 52us, and the 640 video pixes it outputs fit into 45.11us, so it exceeds the 720x576 sampling standard.
    – Justme
    Commented Apr 6, 2021 at 22:13

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 vhcm, 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²acm, 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .