Here's an example and explanation on how to set up a 8-bit color palette on the VS23S010 in an efficient way.

VS23S doesn't have a color look-up table, or "palette memory" as it's often called, because adding one to VS23S would have been prohibitively expensive. Instead, it has a versatile micro-code engine that picks bits from the video memory and assigns those to Y, U and V coefficients in the video modulator. Here's one example of usign the microcode engine in an interesting way to make a nice 8-bit palette (256 colours).

Assigning bits from pixel color value to color coefficients

8-bit palettes are attractive from programmer's point of view, because 8-bit colors will have separate pixels in separate bytes (1 byte per pixel), so each pixel is uniquely addressable in the framebuffer memory. When VS23S010 is drawing the picture, it will load pixel data from memory into a shift register inside the microcode engine. The microcode engine picks bits from the shift register into color coefficients Y, A and B. Y bits modify luminance, e.g. set the pixel's brightness. A and B commonly modify the V and U components in PAL YUV colorspace, or Q and I components in NTSC YIQ colorspace (depending on the phase value of the color burst).

A clever and surprising feature of the microcode engine is that bit assignment and shifting are done independently from each other, e.g. bits of the pixel color value can be assigned into more than one coefficient. For example, see the assignment below:

path3220-1.png (8.08 KiB) Viewed 6825 times

This assignment strategy takes, from the 8-bit pixel color value, 6 bits to u color coefficient, 6 bits to v color coefficient and 3 bits to luminance. That results in a large amount of different hues and also dark and bright luminances for most colors.

Below is a picture of the palette, photographed from a modern LCD television:

VS23S010 TV-Out Palette Test.jpg (84.83 KiB) Viewed 6804 times

The large span of variation in the color coefficients results in a nice spread of different hues, which are useful for bright user interfaces, games, animations and such. Also a lot of darker tones are available. The first 8 values form a very near grayscale. The next 8 values have a slightly bluish tone and the last 8 values form a grayscale with a seepia tone.

With the burst value of 0xB5, the microcode that forms this palette can be seen in the picture: "B62, A63, Y33, N10", which reads out:
"- For B coefficient (u) pick 6 bits, then shift out 2 bits.
- For A coefficient (v) pick 6 bits, then shift out 3 bits.
- For Y coefficient (luminance) pick 3 bits, then shift out 3 bits.
- For the final step, pick 1 bit for No coeffient and don't shift any bits."

From the picture below, you can see how this microcode correlates to the bit assignments:

path3220-1.png (8.08 KiB) Viewed 6825 times

The last step of the microcode is needed, because the engine always executes 4 steps from the microcode memory, followed by additional No-Operation steps until the pixel width setting is satisfied.

Colours on the VS23S are not limited to 8 bits, or even 16 bits; the maximum color depth is 20 bits per pixel (8 bits for Y, 6 bits for U, 6 bits for V). But 8-bit or 16-bit colors are nice because they allow individually addressable pixels.

PS. One final note. In the picture above, also value of d139 was written to register 2d, making the line count odd. This, together with the line length setting, has the effect of making the color carrier be in opposite phase in successive frames, which helps the TV to separate color and luminance. That makes the picture better.
-Panu

Here's a tool for exploring the various colorspace options in the VS23S010.

vs23s010 microcode simulator 01.png (69.95 KiB) Viewed 6767 times

We wrote a simulator, that (partially) simulates the microcode engine inside the VS23S010D and shows what kind of palette results from a given microcode. Also you can modify the color burst vector, which gives a lot of extra freedom in selecting the colors, especially in NTSC, which allows to select the color burst vector freely. In PAL you're limited to the diagonal values in four quadrants because the PAL colorsystem automatically corrects any "distorted "burst vectors.

I hope this tool will be useful. It will show the palette as colours, and list the RGB values for each colors in the palette so you can copy-paste the list of colors. I know this tool is not the most user friendly - you must enter the microcode as a properly formatted string - but there's a few examples that you can choose from the drop-down list and use those as basis for modification. Hopefully I'll have the time to enhance the user interface soon, but there's a ton of other work to do.

This tool is based on a command-line version, which will be released separately.

PS. When you transform the image mode to "Indexed" in GIMP to test how a picture would look using the palette, uncheck the box "Remove unused colors" to keep the palette in order. Use dithering with care, because dithering with two strongly different colors/luminances will result in color noise in the TV picture. Finally use real hardware to check what the picture really looks like.

Due to the automatic color burst phase correction in PAL systems, PAL palettes have much less freedom than NTSC palettes. In general, PAL palettes must have a diagonal colorburst (U and V coordinates must be on a diagonal axis) while NTSC palettes can set the burst orientation, and thus rotate the color constellation, freely. So NTSC palettes are not generally representable in PAL, but some PAL palettes can be represented in NTSC. To convert a PAL palette into NTSC, you must get the correct color phase for both systems. For the PAL burst orientation of 135.0 degrees (burst value of 0xE2, for example), the conversion is simple: for same values of U and V, merely the color burst must be rotated to by 45 degrees to 180 degrees (burst values of 0xD0). PAL palette "P:E2:A22:B22:Y44:N10" corresponds to NTSC palette "N:D0:A22:B22:Y44:N10".

However, due to the asymmetrical alignment of the color constellation for small bit depths of U and V (using two bits for U or V results in the possible values of {-2, -1, 0, 1} only), the color map doesn't quite reach nice reds, for example. This can be alleviated by rotating the color constellation by 180 degrees so that the furthest constellation point (-2, -2) points to red. To covert this colorspace to NTSC, swap the U and V components and adjust the color burst phase by 45 degrees. If you also minimize the amplitude difference of the PAL and NTSC colorburst vectors, the colors can be gotten to be quite accurately the same (within 1 percent). The PAL palette in this case is "P:EE:A22:B22:Y44:N10" and the corresponding NTSC palette "N:0D:B22:A22:Y44:N10" is almost exactly similar.

To decrease the color intensity (saturation), increase the color burst's amplitude. A low intensity color version of this palette would be P:BB:A22:B22:Y44:N10 for PAL and N:09:B22:A22:Y44:N10 for NTSC.

Here's VS23S010C using this color palette in a tile graphics testbench:

Here's a new version of the Microcode Simulator, which now contains a Palette Editor. You can design 256 color palettes using the integrated palette editor and then convert them to the VS23S010 colorspace for the microcode that you are using. You can save and load palettes, edit them by hand, set up gradients and even load a JPG picture into the editor and pick colors from the JPG picture with a mouse click.

rainbow.png (136.32 KiB) Viewed 5230 times

After designing the palette, you can try several conversion methods to convert the ideal palette to the VS23S colorspace. You can go back to the main window to change the colorspace and then reconvert the palette to see if some other microcode would yield nicer colors for your application.

Finally you can export a conversion table as a C file to include in your programs.
Have fun!

JimDrew wrote:This program is fantastic! I can really tweak the microcode to get better results with some of the palettes. You should get a raise for this! Really, this is the biggest issue with using your chip for applications that need RGB equiv. A few percent off is really not noticeable, and you can really tweak the microcode to get under 1%. I really wish this program would have been available a year ago!

One more suggestion - when a change is made to the microcode input, you should update the palette editor output window if the palette editor is open. Right now, while experimenting with different microcode requires that you either close and re-open the palette editor or click on a palette conversion algorithm to see the change to the output window (so no update occurs automatically). I am looking primarily at the total RGB deviation percentage value.

Hi, Jim! Thanks for your great feedback!

I fixed a bug in the palette converter and also tweaked the error estimation routines based on the non-idealities of the YUV conversion matrix. The palettes should be rendered cleaner now on real hardware, even though you may see a slight increase of calculated total deviation. I also implemented your request