Looking for feedback on CGRAM layout table
Moderator: Moderators
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Looking for feedback on CGRAM layout table
I started working on a CGRAM layout table just like I did for the OAM layout table. Is my understanding of how CGRAM is interpreted by the PPU correct?
- Attachments
-
- CGRAM layout.xlsx
- (22.09 KiB) Downloaded 89 times
Re: Looking for feedback on CGRAM layout table
Rather than attaching an Excel spreadsheet (that some of us might not be willing or able to open), could you post a screenshot?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Looking for feedback on CGRAM layout table
Here you go, with the text at the top, sources, and the table as PNG:
Sources:
http://problemkaputt.de/fullsnes.htm#sn ... rectcolors
https://www.raphnet.net/divers/retro_ch ... esdoc.html
edit: the forum seems to have compressed it somewhat aggressively and it's missing some rows at the bottom, but everything is there in the xlsx file
Jeffy's CGRAM layout table
CGRAM is a total of 512 bytes in size;
consisting of 256 color entries.
How many palettes this memory is sliced into (and how big those palettes are) depends on the current
background mode (and probably other things like whether indirect/direct color is used).
All the columns in this table after "bit layout" are about the different ways CGRAM can be sliced into palettes.
Each of those columns can be thought of as a different way the PPU interprets CGRAM.
Each thick bordered box region in these columns is an individual palette.
Note that, except in a 256-color mode, all CGRAM entries greater than 127 are used for the sprites (this is why 3 of the columns "merge" into a single colum at color #128)
For example, BG in Mode 7 uses 128-colors
Modes 3&4 can be configured to use direct color and not use CGRAM at all, so there is no column for those. (This is called 8bpp direct color and has the disadvantage that you can only control 8 of the 15 color bits per pixel).
However, Modes 3&4 can also be configured to use 8bpp indirect color (the column labeld "256-color BG palette")
These 8bpp tiles, having 8 bitplanes, can index the entire CGRAM space.
In these modes configured as such, the entire CGRAM space is interpreted as a single palette of 256 colors and the 3 palette bits in each high byte of VRAM will not be used.
Sources:
http://problemkaputt.de/fullsnes.htm#sn ... rectcolors
https://www.raphnet.net/divers/retro_ch ... esdoc.html
edit: the forum seems to have compressed it somewhat aggressively and it's missing some rows at the bottom, but everything is there in the xlsx file
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Looking for feedback on CGRAM layout table
I found out which half of the sprites are affected by color math from nesdoug:
https://nesdoug.com/2020/06/16/color-math/Color math only affects some sprites. Only sprites that use palettes 4-7 are affected by color math. That is why Mario (and the little ghosts) are solid.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Looking for feedback on CGRAM layout table
I found a slight problem in the second sentence here:
https://problemkaputt.de/fullsnes.htm#s ... rectcolors
You can actually control 11 bits in direct color mode, but these 3 extra bits you can only control on a per-tile basis, not per-pixel. So there are really 2,048 unique colors you can display onscreen at a time, not just 256, but you are limited to 256 colors per tile. Since there is only one "palette" in CGRAM-less 8bpp direct color mode (or more correctly, there are no palette boundaries), it doesn't make sense to have the 3 palette bits that live in each tile's BG map VRAM entry to index into CGRAM. These 3 bits instead contribute (like the C "union" keyword allows variables to serve double-duty) one more bit per color channel. The LSB of each color channel in direct color mode can be thought of as being filled in with zeros, so:
8 bits controllable per-pixel (two blue bits, three green and three red) +
3 bits controllable per-tile (one blue bit, one green bit, and one red bit) +
3 bits that are always clear =
the full 15-bit native SNES color format
while reading the Direct Color Mode section of fullsnes:Modes 3&4 can be configured to use direct color and not use CGRAM at all, so there is no column for those. (This is called 8bpp direct color and has the disadvantage that you can only control 8 of the 15 color bits per pixel).
https://problemkaputt.de/fullsnes.htm#s ... rectcolors
You can actually control 11 bits in direct color mode, but these 3 extra bits you can only control on a per-tile basis, not per-pixel. So there are really 2,048 unique colors you can display onscreen at a time, not just 256, but you are limited to 256 colors per tile. Since there is only one "palette" in CGRAM-less 8bpp direct color mode (or more correctly, there are no palette boundaries), it doesn't make sense to have the 3 palette bits that live in each tile's BG map VRAM entry to index into CGRAM. These 3 bits instead contribute (like the C "union" keyword allows variables to serve double-duty) one more bit per color channel. The LSB of each color channel in direct color mode can be thought of as being filled in with zeros, so:
8 bits controllable per-pixel (two blue bits, three green and three red) +
3 bits controllable per-tile (one blue bit, one green bit, and one red bit) +
3 bits that are always clear =
the full 15-bit native SNES color format
Re: Looking for feedback on CGRAM layout table
You have 2048 colors in direct color mode, but if you do some tricky color math stuff, you can get even more colors on screen at once. (IDK, 32768 ?)
I think someone made a demo. (?)
Edit,on second thought, that demo probably just does HDMA to CGRAM
I think someone made a demo. (?)
Edit,on second thought, that demo probably just does HDMA to CGRAM
nesdoug.com -- blog/tutorial on programming for the NES
Re: Looking for feedback on CGRAM layout table
There's a bunch of high-color conversions over the years.
There's 93143's SNES equivalent to the Megadrive's "fantombitmap", which achieves 64x(full height) of 15bpp pixels, which can display 14k-ish colors but with a problematically wide PAR.
There's a very old demo called "32768 Color Demo by Joshua Cain" that uses color math to display the full 15bpp palette (in a strict rigid format, not useful for conversion).
There's the HDMA-triggered partial palette updates that CypherSignal wrote in this thread.
93143 mentioned having an HV-IRQ version of the above that uploads a new 20(ish?) adjacent colors in the palette (instead of 8 arbitrary ones) each scanline.
Tepples has previous mentioned using mode 3's two layers using color math to combine the 8bpp layer with the 4bpp layer to get 12bpp. There's only enough VRAM for 42kpixels of this, however, so you can't get full-screen conversions without some tile reuse. (Letter/pillar/windowboxing is just the simplest way to reuse tiles)
There's 93143's SNES equivalent to the Megadrive's "fantombitmap", which achieves 64x(full height) of 15bpp pixels, which can display 14k-ish colors but with a problematically wide PAR.
There's a very old demo called "32768 Color Demo by Joshua Cain" that uses color math to display the full 15bpp palette (in a strict rigid format, not useful for conversion).
There's the HDMA-triggered partial palette updates that CypherSignal wrote in this thread.
93143 mentioned having an HV-IRQ version of the above that uploads a new 20(ish?) adjacent colors in the palette (instead of 8 arbitrary ones) each scanline.
Tepples has previous mentioned using mode 3's two layers using color math to combine the 8bpp layer with the 4bpp layer to get 12bpp. There's only enough VRAM for 42kpixels of this, however, so you can't get full-screen conversions without some tile reuse. (Letter/pillar/windowboxing is just the simplest way to reuse tiles)