# Color Palette

- smokku

Choosing a color palette for VPU is very important. It defines the characteristic of visuals generated by the machine.

Commodore 64 palette of 16 colors is very unique. Evenly spread and pale, without full brightness colors. With some distinctive colors glaringly missing - like sky blue. It is a product of technical design and limitations of analog hardware part of VIC.

Atari 8bit palette consists of bands of colors of gradient of brightness. It is a byproduct of how GTIA constructs colors in its analog hardware part. Unfortunately limitations of how these colors are selected, cause Atari to either have bands of the same color of different brightness, or bands of different colors of the same brightess. This causes the impression of Atari having less color capabilities than C64.

Plus/4 stands somewhere in between. The colors are based on C64 limited colors, but with additional circuitry to get 8 brightness levels. With grays covered by this addition, there were some color places left to add more base colors. Yay blue! đźŽ‰ Please read Carrionâ€™s article praising +4 colors.

I wanted X65 feel to be similar to C64, +4 and Atari 8bit, yet unique enough to stand different. I decided to have just 8 brightness levels, to convey the feeling of limitations. First color is obvious: 8 levels of gray, but how to chose base for the rest of 16 colors?

Letâ€™s just split the 360Â° of color wheel into even parts, and place base colors there. Then after applying the 8 bands of brightness we and up with final colors.

Not so fastâ€¦ 0% brightness color is black. 100% brightness color is white. No matter the base color. So letâ€™s skip the first and last band of brightness. Keeping the second brightness as starting point will give us 15 colors of the same brightness as the second gray. Keeping the second to last brightness as ending point, will give us 15 colors of the same brightness as the lightest gray. Artists should âť¤ď¸Ź it for shading. This gives us 6 brightness slots to be divided over 8 brightness levels. This makes the equation a bit complicated, but in fact really obvious.

First, an explanation, why do you see a divider `/7`

in the equation. Arenâ€™t we
computing 8 brightness levels? Yes, but we are moving over `0..7`

indexes, so while
`0/n`

makes 0%, what `n`

should we choose so `7/n`

ths be 100%? Of course `7`

.
`7/7`

is 100%.

```
B = 1/7 + x * (5/7 /7)
```

Starting with `1/7`

we take `x`

times a `/7`

th of `5/7`

(7 - 1 - 1 = 5).
Letâ€™s simplify the equation:

```
= 1/7 + x * 5/7 /7
= 1/7 + 5x/7 /7
= (1 + 5x/7) /7
= (7/7 + 5x/7) /7
= (7 + 5x)/7 /7
= (7 + 5x)/7 * 1/7
= (7 + 5x) / (7 * 7)
= (7 + 5x) / 49
= (7 + 5 * x) / 49
```

Done? Not Yetâ€¦ When plugging this values to `HSB()`

model function, we need to provide
a color Saturation value. Saturation of 0% will give us a band of grays, so scratch that
and letâ€™s plug 100%. This gives pretty usable colors, but in my opinion overly saturated.
100% saturation colors are characteristic of ZX Spectrum and Amstrad CPC, which is not
the look I am going for. We need to de-saturate colors somehow. Quick experimentation
plugging some non-100% values of saturation make edge colors (very dark and very bright)
to blend - they loose distinction of colors.

So, letâ€™s keep edge colors at 100% saturation and have middle colors at 50% saturation.
Is there a function that goes from `1`

to `0`

and back to `1`

? Sure there is: `cosine()`

.
After extending the function period to `7`

, lowering the amplitude to `1/4`

and
moving it up `3/4`

I have what I need.

```
cos(1/7 * 2Ď€ x)/4 + 3/4
```

After plugging the equations to some simple JavaScript and generating visualization in HTML table, the result was still a bit over-saturated overall.

Letâ€™s damp it whole a notch. Replacing `+ 3/4`

with `+ 5/8`

,
I ended up with the following palette of colors:

Letâ€™s check how it performs liveâ€¦ Recolored Carrionâ€™s Tiger image looks like this:

Color me impressed! đźĄł