# Limiting factor on early color palettes

Early color computers typically had a limit of X colors used simultaneously from a palette of Y, a classic example being the Commodore 64 which could do 320x200 monochrome or 160x200 four colors, chosen from a palette of sixteen.

The limitation on the number of colors used simultaneously is a straightforward matter of memory bandwidth: it just wasn't possible (within the budget of a home computer) to pump more bits to the video chip per frame.

What's the reason for the limited palette size? Intuitively it would seem straightforward to e.g. have a palette of 65536 colors; it would just be a matter of having a few 16-bit registers in the video chip, easy enough even given the technology of the day. The resolution of the digital to analog conversion circuitry would need to be improved, but that doesn't seem like it should cost very much.

What am I missing?

• Note that 320*200*2 is equal to 160*200*4; timing was everything when writing software for these machines, and the video interrupts had to come after a precise number of cycles. It's no good writing code that might or might not finish in time depending on the resolution. – wizzwizz4 Jan 27 '17 at 21:19
• Most home computers didn't have palette-based video circuitry at all. The ones that had are exceptions, IMHO. – tofro Jan 28 '17 at 10:03
• @tofro Which ones didn't? – rwallace Jan 29 '17 at 10:41
• @rwallace All of the Sinclair computers, the Tandy Color computer, the BBC Micro.... Commodore and Atari were exceptions. – tofro Jan 29 '17 at 10:52
• The ZX Spectrum had a fixed palette, but the BBC Micro could have used a larger palette since other 6845-based systems did.The Amstrad CPC - another 6845 machine - had an oddly limited 27 colour palette, and in Mode 0 you could pick any 16. – scruss Feb 4 '17 at 16:46

What's the reason for the limited palette size? Intuitively it would seem straightforward to e.g. have a palette of 65536 colors; it would just be a matter of having a few 16-bit registers in the video chip, easy enough even given the technology of the day. The resolution of the digital to analog conversion circuitry would need to be improved, but that doesn't seem like it should cost very much.

What am I missing?

Long story short: to minimize design, test and manufacturing costs.

Long story: IMHO, there are some factors that limit both the number of distinct colors (entries) a palette can have, and the size (number of bits( of a palette entry:

• Of course, more colors means more bits per pixel, and memory was a scarce resource. But in addition, there is something more that must be taken into account: the more entries a palette have, the more complex is the management of the LUT that translates from an entry to an actual color:

• A LUT is seen as a ROM (fixed palette) or RAM (user defined palette). Such LUT needs a decoder with 2N outputs (where N is the number of bits of a pixel). So, for a 4bpp, the LUT needs to be implemented with a 1:16 decoder. For a 8bpp, you need a 1:256 decoder. The more outputs a decoder needs, the more space it will need inside the video chip. Take into account that this LUT will be accessed at the frequency of the pixel clock (if not faster), so the LUT decoder cannot be implemented by chaining together several smaller decoders, as this would introduce a very long propagation time, but with one big decoder.

• Besides, an user defined palette needs the LUT to be implemented with RAM. RAM that would be read by the video engine, possibly at the same time the CPU writes a new value to one of their entries. A small LUT can be implemented with latches and muxes so a read operation can be performed at the same time as a write operation (dual port memory), but if the number of entries increases (and every added bit to the color of a pixel doubles the number of entries), implementing a dual port memory becomes harder with the space constraints in a chip of that time.

• Leaving aside full custom implementations, like the VIC-II chip, most video chips were implemented using some form of gate array, which is a digital-only device, so no internal DACs were possible, which also means that a N bit color would need N pins at the gate array that would be connected to some form of DAC. To simplify the design (and to reduce manufacturing costs), dual in line chips were used as gate arrays (ULA in the Spectrum and Oric, GA in the Amstrad CPC), and these come normally with a pin limit of 40 - 48 pins. After reserving pins for power, clock, data, address, sync signals, etc, there were a few pins left to output the video signal in digital form. A 16-bit color signal would eat 33% of the available pins of a 48 pin gate array. The Amstrad CPC gate arrray, for example, used a trick to have 3 possible states per output pin, allowing 27 unique colors with 3 pins. This was possible by driving each output pin high, low, or leaving it in high impedance state. A resistor divisor placed at each pin would generate three different voltages for each state, thus 33=27 colors.

• 16 or 24 bit palette entries would need either more I/O memory locations (or I/O ports for the Z80 architecture), or a more complex I/O decoding implementation. Both approaches would go against system simplification and cost reduction, as it was usual to do lazy decoding to reduce glue logic gate count. OTOH, a palette entry wider than 8 bits would need some more code to initialize it, and games that would use several palettes would need more RAM to store such palettes. And don't forget that memory was a scarce resource.

• Some machines, like the Oric Atmos, generated their own composite video signal with discrete components instead of using an off-the-shelf PAL encoder (LM1889, MC1377, etc). The key component of Oric's PAL encoder is a small PROM that uses the R,G,B and SYNC signals from the ULA (among others) to get a composite video signal straight from the PROM output data, after D/A conversion. Using more bits for R,G or B would have a bigger (and possibly more expensive) PROM to be needed.

• One simple addition to your list is that each time the palette is bigger, the screen takes more ram and we didn’t have much ram and it was very slow; adding more bits to the palette LUT would mean more memory used and less ram cycles for the CPU which would have simply had to move more data – Thomas Jan 28 '17 at 0:53
• Many machines with LUTs (including PCjr, EGA, and VGA) didn't allow glitch-free updates within the displayed portion of the raster, which avoided the need for dual-port RAM. For non-configurable colors or aspects of colors, one could reduce the size of a LUT by having some (or all) bits of the color designator affect the color bits in logical function. For example, the Amiga had a 64-color mode which used a 32-entry LUT plus a bit which would cut the RGB values in half. – supercat Feb 6 '17 at 3:14
• Seems like instead of a PROM, the Atmos could have used a RAM (maybe a SN74LS319 or something, plus of course the logic needed to map it to the CPU's address space) or something, to actually allow any colour on the screen, instead of only those in the PROM. That would be similar to what rwallace meant by "having a few 16-bit registers in the video chip" – Wilson Nov 8 '18 at 8:40

What you're missing is that early computers didn't generate their video signals the way that modern computers do.

You're probably picturing a C64 working in much the same way that a VGA adapter does: you specify a color index to RGB mapping, and a digital-to-analog converter looks up that mapping and generates appropriate red, green, and blue signal values.

Color computers didn't work that way. Generally, they synthesized a composite video signal directly in the analog domain by modifying the color carrier; there is no digital-to-analog converter. The VIC-II, for example, used an analog adder to combine four versions of the carrier in appropriate proportions to produce its 16 colors; each color had a (mostly) independent circuit. Increasing the number of available colors isn't just a matter of adding a few lookup registers; you'd also need to add the circuitry to turn those registers into YIQ/YUV values.

• It's probably worth noting that when VGA came out with the PS/2 in 1987, its use of an analog external signal was a new idea as far as IBM PC-compatibles were concerned. Of previous graphics adapters for the IBM PC, MDA (1981) was digital, CGA (1981) was digital but could be used with a composite monitor, and EGA (1984) was digital. – a CVn Jan 28 '17 at 14:03

First, the Commodore 64 could do better than 320x200 in monochrome. Without any special tricks, it could display two colors per 8x8 cell at that resolution.

One reason of the limited color palette comes down to how much logic you could cram into one chip. Take the Atari 800. It was able to produce roughly 128 colors (later, 256) but it actually had TWO chips. One to render the monochrome image and the other to add color, sprites, etc.

The VIC-II in the Commodore 64 is just one chip.

Another reason is that a disproportional area of the VIC-II chip was dedicated to sprite rendering. The Commodore 64 had some of the best sprites of any 8-bit machine and that sprite ability came at a cost. Reduced functionality in other areas of the VIC-II.

The VIC and VIC-II were never really designed for advanced computers. They were designed BEFORE the Commodore 64 was out (late 70's, early 80's). They were also mainly designed for things like computer kiosks and early arcade machines.

Now, look at the Apple II. The fact that Apple had COLOR AT ALL in a "somewhat" affordable machine in the late 70's is amazing. But the Apple II cheats by using NTSC artifact fringing. Which severely limits the number of available colors.

Other 8-bit machines had similar issues. They were designed either too early for advanced graphics or made way too cheap for them (i.e., Mattel Aquarius).

When the 16-bit machines came along (not counting B/W Macintosh), around 1985 or so, color was much more "doable". And you start seeing real color DAC's, etc.

• The Apple II color had lots of weird features, my IIc had effectively 15 colors in lowres mode because the greys were identical. Woz's obsession with the lowest chip count and video games lead the Apple II to some strange video modes. Given how expensive chips and computers were in the 70's-80's color was a do what you can kind of thing. – Michael Shopsin Feb 2 '17 at 20:00
• @MichaelShopsin: Whether the two "grays" appear identical will depend upon how the calibration of the attached monitor. Color 5 is a combination of colors 1 and 4, while color 10 is a mixture of 2 and 8. On some monitors the hues of colors 1 and 4 cancel, and likewise 2 and 8. I the hues don't perfectly cancel, colors 5 and 10 will appear different. – supercat Feb 6 '17 at 3:21
• @supercat on my IIc's color monitor the grays appeared identical, while they can be told apart on my IIgs's monitor. I did my BASIC programming on the IIc and IIe where the grays were identical. – Michael Shopsin Feb 6 '17 at 15:45
• @MichaelShopsin: From a hardware standpoint, the Apple ][ and its descendants all output the same composite-video waveform in lo-res mode. For colors 5 and 10, they both output a square wave at twice chroma frequency. For one [I forget which], the rising edges of the square wave occur on the edges of the chroma reference; for the other, the falling edges coincide with the edges of the chroma reference. – supercat Feb 6 '17 at 16:40

CGA (1981) monitors have digital TTL RGBI inputs (red, green, blue, and intensity), giving you a fixed palette of 16 (24) colors:

## | I R G B | Color
---+---------+--------------
0 | 0 0 0 0 | black
1 | 0 0 0 1 | blue
2 | 0 0 1 0 | green
3 | 0 0 1 1 | cyan
4 | 0 1 0 0 | red
5 | 0 1 0 1 | magenta
6 | 0 1 1 0 | yellow
7 | 0 1 1 1 | light gray
8 | 1 0 0 0 | dark gray
9 | 1 0 0 1 | light blue
10 | 1 0 1 0 | light green
11 | 1 0 1 1 | light cyan
12 | 1 1 0 0 | light red
13 | 1 1 0 1 | light magenta
14 | 1 1 1 0 | light yellow
15 | 1 1 1 1 | white
--+----------+--------------


So in this case, the palette was a hardware limitation, specifically in the monitor.

EGA (1984) was also quantized like CGA but supported 4 voltage levels (2 bits) per R, G, and B for a total of 64 colors (43).

Later, VGA (1987) abandoned digital signal levels and switched to analog. Then the limitation on the number of colors was no longer in the monitor but in the VGA circuitry itself. Standard VGA supported a palette of 6 bits per pixel and color (26*3) for a total of 262,144 colors, but only 256 of those colors could be used per frame. Later, high color modes supported 16 bits per pixel (216 = 65,536 colors, usable in a single frame) and then 24 bits (224 or ~16.7 million colors). All of this was possible using the same monitors as standard VGA because those monitors were all analog.

But back to 8-bit computers, the Atari 2600 (1977) had a palette of 128 colors (NTSC) or 104 colors (PAL) and could display all of these colors in the same frame, without a framebuffer, by providing a way for the programmer to synchronize with the electron gun and change the colors of the background, playing field, and 2 sprites and 2 missiles from one scanline to the next. (See this demo for some examples.) Later 8-bit computers with framebuffers could only display 16 colors on the screen at a time. How's that for progress? :-)

• It may be worth noting that some early versions of SVGA supported 15 bit color (16 bit internally, but 15 bit rendered). Meaning 32,768 colors. Often a level of green was sacrificed because the human eye is more sensitive to green. – cbmeeks Jan 30 '17 at 13:31

The Atari 2600 supports 128 colors because it was easier to have four 7-bit color registers along with circuitry independently generate one of eight luminance levels and one of sixteen chroma phases, than to have four 4-bit latches along with circuitry to convert a 4-bit value into one of sixteen useful colors. The Atari 400 and 800 have a few more color registers, but not a huge number, and so they simply follow suit.

The Commodore VIC-20 uses a 4-bit RAM chip on a dedicated data bus to independently select one of two display modes and one of eight foreground colors for each character. Although the VIC chip generates colors electronically in much the same way as the 2600, it was cheaper and easier to have a 4-bit ROM to map 16 colors into luma and chroma values, along with 11 register bits for the border, background, and aux colors, than it would have been to have eleven 7-bit registers for the eight font colors along with the background, border, and aux colors. Further, having color numbers 0-7 map to eight fixed colors made it possible to have labeled key functions (control 1-control 8) to select those colors. Adding palette mapping might have made that more confusing.

The C64 followed in the VIC-20's footstep except that light magenta, light cyan, and light yellow are replaced by shades of gray, and it defaults to using the upper bit of each character's color to select colors 8-15 rather than selecting an alternate display mode. I think it would have been great if the C64 had included 16 seven-bit-wide palette registers, but a 16x7 ROM is cheaper, and the C64 beat pretty much everything but the Atari computers anyway.

Many video chips use an 8-bit data bus to fetch bytes that select a foreground+background combination. Going beyond 16 colors would require the use of two fetches per byte or else--as with the C64--adding 16 7-bit registers. The VIC-20 and C64 are unusual in that their chips actually fetch data 12 bits at a time (8 from main memory, and four from a secondary color RAM); upgrading the color RAM to 8 bits would not only require adding another 1Kx4 RAM chip and another chip to selectively couple its 4 data lines to the main bus during CPU access, but would also require somehow getting another 4 bit lines into the video chip which was crowded enough as it was.

Static RAM is expensive in terms of size and early gate arrays didn't have much of it. In a fully custom ASIC design you could allocate more space for memory, but still uses up a large part of your die and you will need other various small memories too, so there's a trade-off to be made.

In applications where a large palette was necessary, typically arcade games, they used external PROMs or RAMs to implement the palette as it was expected to occupy a large PCB. This relaxed the need for large memories in the custom parts.

For home computers and consoles the primary goal is to reduce cost (closely tied to pin count) and PCB space so it was more important to use on-chip memory for the palette.

To give you some idea of approximate memory sizes where the palette was on-chip:

• Atari 2600 : 4 words of 7 bits (28 bits)
• SMS, NES : 64 words of 6 bits (384 bits)
• Amiga : 32 words of 12 bits (384 bits)
• Genesis : 64 words of 9 bits (576 bits)
• SNES : 256 words of 15 bits (3840 bits)
• PC Engine : 512 words of 9 bits (4608 bits)
• PC VGA video card's RAMDAC : 256 words of 18 bits (4608 bits)
• 32X : 256 words of 16 bits (4096 bits)
• Saturn : 4096 words of 16 bits (64K bits)

On the whole they are all quite small due the competition of resources on the same die. It's worth noting that this spans a very long time in terms of technology, and the Saturn is definitely the odd one out.

• Atari 2600: 4 words of 7 bits (28 bits total). – supercat Jun 18 '18 at 15:19

I think a big part of the answer is that it was good enough at the time. Given the crudity of the resolution and number of simultaneous colors, having a bigger palette wouldn't have added much to the overall experience.

Games at the time were more primitive (though they always pushed the limits), and basic business charts and graphs can still be quite useful with a small palette.

Also, generating good, repeatable colors with NTSC on cheap hardware isn't so easy. Keeping it to the basic fully saturated "guy colors" of red, green, blue, yellow, black, white, etc. is easier to achieve.

• I think a lot of the hardware was designed before people realized how useful something like the 2600's color palette could be. There are a number of games which look better on the 2600 than on any non-Atari 8-bit computer because they make good use of shading and gradient effects. I think if such games had been written for the 2600 before the design of the C64 had been nailed down, Commodore might have opted to expend the silicon necessary to match such graphics. – supercat Jan 29 '17 at 18:39
• @supercat Commodore wasn't about creating excellent machines. It was about Tramiel selling whatever he had sitting around the warehouses or whatever he could have designed in a few months. We all just got lucky that the VIC-II and SID managed to land in the same machine. I would say we got lucky a second time with the purchase of Amiga but if that didn't happen, Atari would have sold Amiga's instead. – cbmeeks Jan 30 '17 at 19:39
• Carl Raymond: Now that we know what guy colors are, can you let us know what "gal" colors are? – cbmeeks Jan 30 '17 at 19:41

In many systems, the colour palette was fixed. This was either because they were easy to generate on the available hardware components or because it was easier to hard-code them.

Take the Commodore 64 as an example. This computer used the MOS VIC-II to render the video, which determined its video modes and colour palette. The palette was chosen mostly arbitrarily; it was a YPbPr palette where the Pb and Pr coordinates were sine and cosine (respectively) of angles multiples of one sixteenth of a circle, and many colours were opposite others in the NTSC colour wheel to save on resistor values.

The Apple II uses a different technique. It exploits NTSC colour artefacts to generate colours cheaply. In hi-res graphics, horizontally adjacent colours are averaged on NTSC displays, so two colours are outputted per carrier cycle. When an odd pixel is on and an even pixel is off, the displayed colour of the pixels is green; switching them gives purple. When both are on the colour is white, and when both are off the colour is black. By shifting these a half-pixel, orange and blue can also be produced, giving a total of 8 colours (including two whites and two blacks, which were visually identical but produced different artefacts at areas of contrast). Low-res graphics are created using the text generator circuitry, allowing up to 16 colours (including two identical greys) but at the same resolution as text.

Colour generation was often optimised for simplicity at the hardware level and, by extension, manufacturing price. This means that you can manipulate it at a low level in unintended ways, but it also comes with restrictions.

Further information:

• This answer's a bit rubbish. I'll improve it later. – wizzwizz4 Jan 27 '17 at 21:48
• How much later? :-) – a CVn Jan 30 '17 at 11:55
• @MichaelKjörling Sometime after Wednesday. I don't have enough time now (and didn't really when I posted this answer!) – wizzwizz4 Jan 30 '17 at 16:52
• No worries as far as I'm concerned; consider it just a gentle reminder. – a CVn Jan 31 '17 at 8:26
• Still waiting for the improvements... Thanks. – Tim Locke Nov 8 '18 at 16:58

Having a larger palette range is not necessarily without issue either. If you look at the Amstrad CPC+/GX4000 models, they increased the palette range from 27 to 4096 colours. While that certainly allows for better graphics, only being able to have a very limited subset of those colours onscreen limits how effectively you can use them for shading effects etc. And since palette entries become two bytes long, it is no longer possible to make an atomic change to any given palette entry (since the Z80 only has an 8-bit data bus, a 16-bit write happens in two parts) changing colours mid-frame causing artifacting effects with the red/blue level of a colour changing before the green level, unless you are very careful with timing.

The main limiting factor was memory bus bandwidth.

Both the Commodore 64 and Amiga are good examples of this. Their maximum resolutions are limited by the amount of memory bandwidth available - the system simply can't read data quickly enough to produce a higher resolution display.

Say that a hypothetical system can read 80 bytes per scanline. If each pixel requires one byte to select one of 256 colours, the maximum horizontal resolution is 80 pixels. If we reduce to 16 colours we only need 4 bytes per pixel, so a horizontal resolution of 160 is possible. At 4 colours we can manage 320 pixels per line, and at 2 colours we can do 640.

As well as the maximum amount of data that can be read, there is a trade off for performance. On the Amiga higher resolutions and more than 16 colours results in the video hardware needing more memory bandwidth, which is taken away from the CPU and graphics processor. Games and applications had to decide how much CPU and blitter performance they were willing to sacrifice to get more colours on screen.

• This explains why the Commodore is 4 of X colors, but the question is asking why "X" is 16 rather than 65536. – Mark Jun 20 '18 at 0:57