Palettes: Difference between revisions
mNo edit summary |
m (Access section, max number of colors) |
||
| Line 1: | Line 1: | ||
[[File:Palmap.png|thumb|Palette organisation]] | [[File:Palmap.png|thumb|Palette organisation]] | ||
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. | 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. | ||
[[Sprites|Sprite]] tiles can use any of the 256 palettes, while the [[Fix layer|fix]] tiles can only use the 16 firsts. | [[Sprites|Sprite]] tiles can use any of the 256 palettes, while the [[Fix layer|fix]] tiles can only use the 16 firsts. | ||
The maximum number of colors on screen without [[ | 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== | ==Special colors== | ||
| Line 31: | Line 28: | ||
Each color component is coded with 6 bits, with 1 common LSB, effectively making full use of the 16 color definition bits. | 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 {{Sig|PAL|PAL}} 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 {{Reg|REG_PALBANK1}} or {{Reg|REG_PALBANK0}}. | |||
=Converter= | =Converter= | ||
| Line 38: | Line 47: | ||
[[Category:Video system]] | [[Category:Video system]] | ||
[[Category:Interactive pages]] | |||
Revision as of 22:45, 17 April 2016
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 NEO-B1 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
| Bit | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Def | Dark bit | 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 PAL 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 REG_PALBANK1 or REG_PALBANK0.