Palettes

There are 2 banks (one usable at a time) of 256 palettes available. Each palette has 16 entries, the first is the transparent index ("color 0"), the 15 others are real colors, made of 16bit RGB definitions.

Sprite tiles can use any of the 256 palettes, while the fix tiles can only use the 16 firsts.

The maximum number of colors on screen without timer interrupt tricks is: 256 palettes * 15 colors + 1 backdrop color = 3841 (out of 2^16 = 65536).

Special colors
There are two special colors used:


 * The first color of the palette bank ($400000) is the reference color for the video output. It has to be $8000 (black) otherwise monitors won't be happy and other colors won't be displayed correctly.
 * The last color of the palette bank ($401FFE) is the backdrop color (the color of the backmost layer on the screen). Caused by line buffers in being cleared to $FFF (Last color of last palette).

Color format


D R0 G0  B0  R4 R3 R2 R1  G4 G3 G2 G1  B4 B3 B2 B1

Each color component is coded with 6 bits, with 1 common LSB, effectively making full use of the 16 color definition bits.

The top 4 bits of each component fits in 3 nibbles, making it easy to write or guess color values ($0F00 is red, $00F0, is green...).

Access
Palettes are located at $400000 in the 68k memory map, and they're physically stored in the palette RAM.

Byte access may be allowed, but it will trash the corresponding word's other byte (/WE are tied together). Maybe NEO-C1 doesn't assert during byte access ?

Palette can be read and written at any time. During active display, since the CPU has priority over rendering, the color read or written will be displayed for at least one pixel, resulting in noticeable "snow" if multiple palettes are updated. A workaround is to update the palette only during blanking (horizontal or vertical), over multiple frames if necessary.

The bank can be set by writing a byte to registers or.

=Converter=