18

The MOS VIC in the VIC-20 and the MOS VIC-II in the C64 were capable of outputting 16 colours drawn from a hard-coded palette.

It's clear that the palette size was fixed at 16 colours as a memory-saving measure. It's also clear that it is immensely helpful for there to be some default assignment of colours to this palette. But why was no provision made for changing this default assignment?

As I understand it, the VIC-II directly generates its video signal in terms of YIQ or YUV, with one luminance and two chrominance signals. Rather than hard-coding the three YIQ/YUV values for each of the 16 colours in the palette, would it not have been possible to allow the user to specify them via memory-mapped registers? I understand that YIQ/YUV values are real-valued, but surely these could be quantized into 256 values to fit into a byte, or into 16 values to fit into a nybble? In fact, it seems that this sort of quantization is exactly what MOS did for the Plus/4's TED, where the [0,1] luminance space is mapped to eight discrete values.

Would allowing a custom palette have been considered too expensive or complex to do back in 1981 when the VIC-II was designed? Or did the designers simply not anticipate that there would be any need for user-definable colours?

Improve this question
2

3 Answers 3

Reset to default
13

We can of course only guess why, but with a fixed palette, it only needs to implement the circuits you need to get the 16 predesigned colors based on the color index. Cheaper, faster, and they were already in a hurry.

The color index is just used to index a look-up tables what resistances to select in the signal path. There are separate lookup tables to select resistances for luma Y and both U and V components of chroma, which are basically used together to select hue and saturation.

Having a selectable palette would have needed to implement a user programmable CLUT registers instead of fixed CLUT for the 16 colors, and implement more resistors to be able to select a reasonable amount of Y, U and V signal levels from the CLUT.

Even with 8 levels or 3 bits per component, you have three components and 16 colors. So 144 bits of CLUT. Then each 3 bit value must select 8 different resistance values for the component. And they were already having problems with the tolerance of the luma resistances to get similar colors out. They decided to not include an adjustment pot for cost reasons as it was determined good enough already.

Improve this answer
4
  • If one were willing to tolerate having a pixel use the color of the one to its left during any cycle where the CPU accessed any of the color registers, a 32x6 or 32x7 CLUT would probably have been more compact than the 15x4 dual-port RAM the part actually used.
    – supercat
    Jan 4 at 18:36
  • @supercat What dual port RAM is used and where? In relation to VIC-II color that is.
    – Justme
    Jan 4 at 19:00
  • 1
    On the die shots I've seen, the color register storage is a vertical block near the right edge of the chip, just above a horizontal block. Resolution was insufficient to see exactly what's going on, but the layout is a lot less dense than I've seen for RAM which doesn't need to allow a simultaneous read from one address and write to another. Such access would occur when the 6502 executes a store to a color register at a time when a different color is being displayed.
    – supercat
    Jan 4 at 19:03
  • If one looks at mayhem64.co.uk/c64design2.jpg block "A" holds 480 bits, compared with 60 bits for block "K, but block A is nowhere near eight times as big. If software readback weren't required, Taking 40% of the width of A and half the height would yield an area about the size of K, which should be sized about right to hold 32x6 color registers.
    – supercat
    Jan 5 at 23:35
11

While I would doubt that a 16x8 ROM would be cheaper than an 8-bit register or even four of them (which is probably why the Atari 2600 allows a wide range of colors, but leaves me puzzled at the SID chip's ADSR design), the VIC-II chip has fifteen color registers as well as--more importantly--an attachment for a 1Kx4 RAM chip to hold color selections. Even if the VIC-II internal color registers were all 8 bits, the chip would still need a means of mapping 4-bit color numbers stored in RAM to 8-bit values.

An important thing to recognize when looking back at the design of chips from that era is that it wasn't practical to experiment with different design aspects in the ways that can be easily done today, but was instead necessary to commit to various design aspects which might turn out to be sub-optimal before one could discover, while doing later parts of the design, how earlier parts could have been done better. The VIC-II's design was probably limited by some aspects of the VIC-20's design which, had they not been constraints, might have resulted in a very different chip.

For example, the VIC-II could probably have eliminated the need for a 16-entry color ROM if values from the external attribute memory didn't map to fixed colors, but instead shared colors with the other programmed color function (so e.g. a value of 8 in color RAM would make text the same color as sprite #0). That would probably have saved enough silicon to allow color registers to be expanded to 6-7 bits. This would, however, not have fit well with the idea that color values 0-7 would be be mapped to the colors named on the fronts of the keycaps.

Had the chip been designed that way, it would have not fit well with some kinds of games which have very colorful backgrounds and a variety of colored enemies in front of them, but it could have supported many other game designs that exploit the wider variety of available colors. Deviating from the VIC-20's character-color paradigm, however, would likely have been seen as undesirable.

Improve this answer
6
  • 2
    What's the issue with the SID's ADSR?
    – piiperi Reinstate Monica
    Jan 3 at 9:24
  • @piiperiReinstateMonica: There are 16 settings each for attack rate, decay rate, and release rate, and the values represent lookups into a small ROM holding a table of rates the chip designer thought might be useful. The part has enough address space to accommodate 8-bit rather than 4-bit registers, and there are some rather big gaps in the table, e.g. the slowest five settings are for 2.4 seconds, 3 seconds, 9 seconds, 15 seconds, and 24 seconds.
    – supercat
    Jan 3 at 17:43
  • 1
    You say that as if it was a bad thing? As a musician I want fine resolution in the short time range, like what the SID offers. If the alternative was, say, an 8 bit range of equal spacing over the 24 seconds, it would give 24 s / 256 = 94 ms resolution between values and make the whole envelope feature next to useless. For short response times that would be unusably coarse, and for long times meaninglessly fine. If you want something that would have made sense to improve, the attack phase now always wants to hit full amplitude, and it would be nicer to be able to directly set a level for it.
    – piiperi Reinstate Monica
    Jan 3 at 19:13
  • @piiperiReinstateMonica: I agree with you the full-amplitude hit is a bigger weakness. My intended point was not that the SID should have used an 8-bit register, but rather that if one starts with an 8-bit register one doesn't need to worry about whether all values are equally usable. One could, for example, use three bits to select a tap in a power-of-two frequency divider (so the value in the bottom 5 bits is added/subtracted from the volume accumulator every cycle, every sixteenth, every 64th, etc.) and the bottom 5 bits as a raw value to add/subtract. Usable values wouldn't be...
    – supercat
    Jan 3 at 19:44
  • ...equally spaced, but they'd be dense enough that that wouldn't be an issue. As an alternative, one could have a pair of 4-bit programmed values which were interpreted simply as a power-of-two selectors, and have the chip use them on alternate cycles, which could probably simplify the logic of the add/subtract unit since it would only have to worry about power-of-two addends/subtrahends.
    – supercat
    Jan 3 at 19:51
7

Analog output on TV was a messy process. Back in the early days of Homecomputing, electronics were not as exact as today. Nowhere you could difference on a cheap tv 16 mio. colors (256 brightness levels for red, green and blue) not even speak about generating such fine grained signals. Even worse: the CRTs varied the displayed colors depending on brand, age and temperature and last but not least: the colors tend to "bleed" horizontal on different rates for each component so a yellow pixel left of a blue pixel would make the blue pixel boundary slightly blurry.

This means not only the single color was important, but also its relation with the other 15 colors as well. Also black and white TVs where still a thing in the 80ies, especially as a computer monitor "for the kids", so you need to make sure that your colors are also showing up as different on black and white (luminance only).

I read in a retro books (I think it was in Brian Bagnalls "On the Edge") that they experiment with different colors and tried to space them equally on a hue-circle and then moved some of the colors depending on results on their own TVs in the lab.

For special nostalgia: When the C64 with black border and white background and black texts displayed a basic listing, my TV started to "hum" in different frequencies depending of the amount of black pixels. Switching to the blue on blue standard scheme, the humming was gone.

Everything you do not want to know about VIC-II color generation: Commodore VIC-II Color Analysis

Improve this answer
1
  • 1
    Not even all current monitors truly do actual 24bit colors (6 bit per color panels or 6 bit+FRC panels are common).
    – rackandboneman
    Feb 19 at 23:30

You must log in to answer this question.

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