Page 1 of 1

Looking for feedback on CGRAM layout table

Posted: Sun Jun 05, 2022 4:17 pm
by jeffythedragonslayer
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?

Re: Looking for feedback on CGRAM layout table

Posted: Sun Jun 05, 2022 4:39 pm
by Quietust
Rather than attaching an Excel spreadsheet (that some of us might not be willing or able to open), could you post a screenshot?

Re: Looking for feedback on CGRAM layout table

Posted: Sun Jun 05, 2022 4:53 pm
by jeffythedragonslayer
Here you go, with the text at the top, sources, and the table as PNG:
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

Re: Looking for feedback on CGRAM layout table

Posted: Tue Jun 07, 2022 6:25 pm
by jeffythedragonslayer
I found out which half of the sprites are affected by color math from nesdoug:
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.
https://nesdoug.com/2020/06/16/color-math/

Re: Looking for feedback on CGRAM layout table

Posted: Sat Jun 18, 2022 4:29 pm
by jeffythedragonslayer
I found a slight problem in the second sentence here:
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).
while reading the Direct Color Mode section of fullsnes:

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

Posted: Sat Jun 18, 2022 6:53 pm
by dougeff
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

Re: Looking for feedback on CGRAM layout table

Posted: Sat Jun 18, 2022 7:16 pm
by lidnariq
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)