Colour palette entries

[JonBrawn]

Victor can support eight palettes, one of which (#7) is a user-programmable palette. The default palette, #0, is used when the FPGA first loads, so it should be as much VIC-like as possible.

To that end, I obtained two identical 7" displays that could take composite NTSC/PAL input, two VIC-20s, one with a real 6560, one with the Victor FPGA, and some user-palette reprogramming BASIC. With a bit of twiddling to set the hue/saturation/intensity of each palette entry, I now have the palette entries that I will use for the default NTSC palette. If anybody cares, here are the numbers I obtained:

Code: Select all

<colour> <idx> <hue> <sat> <int>
Black       0    00    0      0
White       1    00    0     32
Red         2    21    3     08
Cyan        3    55    2     32
Purple      4    19    3     16
Green       5    50    3     16
Blue        6    62    2     08
Yellow      7    33    2     32
Orange      8    25    3     08
Lt Orange   9    21    2     32
Pink       10    19    3     32
Lt Cyan    11    55    2     32
Lt Purple  12    17    2     32
Lt Green   13    49    3     32
Lt Blue    14    61    1     16
Lt Yellow  15    29    1     32

Here, the <hue> value corresponds to a phase-shift angle, and the range 0..63 in this table maps onto 0..359 degrees of phase shift.
The <sat> value, the saturation, is how much of that hue is present and has a range from 0 (none) through 3 (full force).
The <int> intensity value sets how bright the colour is overall - if you turn off the colour part of the signal, the intensity (luma) gives the grey-scale level that would be used. The encoding is one-hot, as that is how this DAC is constructed. A value of '1' outputs an HSYNC level, '2' is BLANK/BLACK/0%/SETUP level (cue conversation about how SETUP is supposed to be higher output than BLANK and how that's not what Commodore did), '4', '8', '16', and '32' produce 25%, 50%, 75% and 100% luma intensity. Combinations with multiple bits set don't do anything interesting - the lowest voltage output is the one selected, so '8' overrides '32', for example.

Currently, the chroma colour carrier is generated as a "sine wave" with only 8 sample points per cycle, so pretty sloppy and not as smooth as it could be: 0.0, 0.7, 1.0, 0.7, 0.0, -0.7, -1.0, -0.7, (0.0) While this works, I'm relatively sure it is one of the noise contributors, so I'll be experimenting with a larger number of samples per cycle, provided the PLL in the FPGA can double the current fast_clk frequencies.

How about PAL? Did I manage to get the PAL palettes assigned as well?

Unfortunately, the two PAL-compatible displays I bought are not PAL-compatible - or even match each other. Using the same VIC-20 with the same 6561, one display would display every second colour as festering green, whereas the other would display everything as a random brown.

I need another two displays that can cope with the mangled mess that is VIC-20 composite PAL. My original idea was picture-in-picture, so I'll go back to that idea and see what I can manage to come up with.

[Mike]

Currently, the chroma colour carrier is generated as a "sine wave" with only 8 sample points per cycle, so pretty sloppy and not as smooth as it could be: 0.0, 0.7, 1.0, 0.7, 0.0, -0.7, -1.0, -0.7, (0.0) While this works, I'm relatively sure it is one of the noise contributors, so I'll be experimenting with a larger number of samples per cycle, provided the PLL in the FPGA can double the current fast_clk frequencies.

At least two alternatives or improvements come to my mind here: high-pass filtering the output - which probably happens anyway by means of a loaded capacitive coupling, giving an effective pass frequency -, or employing an analog slope generator so the output does not produce steps but rather slopes. With 8 sample points per cycle, the latter should already do a good job (and the harmonics will be dampened by 1/n² instead of 1/n).

How about PAL? Did I manage to get the PAL palettes assigned as well?

tokra and I once derived palettes for both TV norms. Compared to PAL, the NTSC palette looks somewhat 'colder' and NTSC users should have a hard time telling light orange, light red (a.k.a. pink) and light purple from each other:



NTSC to the left, PAL to the right.

There have also been some discussions on the German forum "Forum64" about phase errors in the Chroma signal between two consecutive rasters. The palettes above have been determined by photographing greater areas and averaging over several raster lines, so they don't take those phase errors into account. This might by relevant when mixing colours by alternating different colours on each raster. For PAL, this effect was investigated with a test image I posted in the thread "Request: PAL mixing test program", unfortunately that one wouldn't work on NTSC.

[JonBrawn]

Yes, I have blatantly stolen the palettes that you contributed to VICE, but neither the VICE hue/saturation/intensity nor the RGB encoding scheme mapped onto what's going on inside Victor particularly well, so what I have are rough approximations of what you determined - you can tell red from blue, sure, but is it the //right// red? Nope! Hence the apples-to-apples comparison using two identical screens, which worked remarkably well, all things considered. And yes, pink, lt orange and lt purple are very close to each other.

As for smoothing, I cannot have any passives between the output of the DAC and the video circuit on the VIC-20 PCB, because there are a multitude of different circuits that have been used, and what might help on one model may completely mess up a different one, hence the desire to use 16 samples per cycle.

[mathop]

Apparently early versions of the 6560 had a different palette where cyan would look more like a light blue rather than the colors described here. (I think I may have one of these.) Could be interesting to create a variant for that too.

[pixel]

By the way: is blue really disappearing like shown below on NTSC machines? (screenshots of VICE)

What should be there:

CRT emulation: