Espozo wrote:That affect is way more limited than more overdraw though. You only have one palette and on the SNES, it has to fit in a 256x128 box. Again, there's not enough bandwidth either.
You can composite to the background, which is what
Hatris,
Zoop,
RHDE, and the
Action 53 menu do. There's more than enough background memory for the whole screen even in 8bpp mode, so long as not everything moves every frame. In
Hatris and
Zoop, the field changes only when pieces are added or removed. In
Action 53 and
RHDE, only one line of text changes in each frame.
Espozo wrote:One thing I wonder though: How can sprites and tiles on the NES even take advantage of more tiles in CHR ROM if they don't have that many bits to select tiles?
Bank switching. A mapper circuit on the cartridge controls the CHR ROM's upper address lines based on values selected by the CPU.
For example, the FME-7, a mapper chip used in later Sunsoft games, divides CHR ROM into 1024 byte banks, and it divides the pattern table address space into 1024-byte windows ($0000-$03FF, $0400-$07FF, ..., $1C00-$1FFF). The mapper lets the CPU select a bank of ROM for each window. When the PPU reads the pattern table, looks at PPU A12-A10 to see which window is being read, and it looks up the appropriate bank number to output on CHR ROM A17-A10.
Example with actual numbers: FME-7 register 5 is the CHR ROM bank number for PPU $1400-$17FF. Bank 19 of CHR ROM is $04C00-$04FFF. The CPU writes a value of 19 to register 5. Then whenever the mapper detects that the PPU is accessing $1400-$17FF (PPU A13-A10 = 0101), the FME-7 outputs 19 (CHR ROM A17-A10 = 00010011), thereby redirecting the access to CHR ROM bank 19.
PRG ROM in excess of 32 KiB needs to be bankswitched as well. The NES, SMS, or Game Boy CPU writes to a mapper register to control upper address lines of the PRG ROM, which makes different parts of the program appear to the CPU.