Looking for feedback on CGRAM layout table

Discussion about the site's wikis, including bugs/issues encountered.

Moderator: Moderators

Post Reply
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Looking for feedback on CGRAM layout table

Post 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?
Attachments
CGRAM layout.xlsx
(22.09 KiB) Downloaded 83 times
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Looking for feedback on CGRAM layout table

Post 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?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Looking for feedback on CGRAM layout table

Post 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
Attachments
CGRAM layout screenshot.png
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Looking for feedback on CGRAM layout table

Post 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/
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Looking for feedback on CGRAM layout table

Post 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
User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: Looking for feedback on CGRAM layout table

Post 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
nesdoug.com -- blog/tutorial on programming for the NES
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Looking for feedback on CGRAM layout table

Post 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)
Post Reply