nesdev.com

Yep.

Shantae doesn't really use special features though (besides artificially locking out a map in GBC mode), it just uses alternate palettes to make up for the fact the GBA's screen is much darker. But yeah, point stands. GBC games running on a GB would be a better comparison (or also SGB games).

What works reasonably well for me is to constantly toggle between two color sets.
For example palette index 1 is 0x14 (#e720a7) in every even frame and 0x15 (#ff1b3d) in every odd frame.
In the average this blends to #f31d72.
This only works for similar colors (or you'll get flickering) and looks much better on analog (interlaced) screens.

NES isn't interlaced, just some HDTVs show it that way.
Some TVs show 240p video as a normal looking screen, other TVs have black scanlines between the rows of pixels.

Some famiclones include a 4bpp mode, and are still backwards compatible with the original NES.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

How does these famiclones' pattern fetch sequence look? Does it require a faster CHR ROM due to fetching every dot rather than every 2 dots?

This is just conjecture, but I would suppose there is just an "extended" CHR bus, with an additional 8 data bits tacked on in parallel: twice the amount of data than usual is being fetched by adding on two planes, and the timings remain the same. A normal NES game would not activate this mode, and those 8 bits would go unused. THe magic would happen in the output stage where the output is muxed from the backdrop color, the BG tiles, or sprites, with just an additional two bits to deal with.

IIRC, the OneBus VT Famiclones were the only ones that supported the higher bitdepth, and their documents explain how they do things...

On the NES, during rendering, every pixel is either a setup cycle or a read cycle; IIRC on the OneBus famiclone, every three pixels are always a CPU bus cycle and two fetches for the PPU, for an aggregate PPU data transfer rate of 3.6MB/s instead of 2.7MB/s. Additionally I don't think the attribute zones work the same way, and sprites might always be 2bpp.

Since the onebus famiclones in onebus mode are fundamentally incompatible with ordinary NES games, there's no real need to retain a compatible fetch sequence.

That would mean 8 CPU cycles and 16 PPU cycles per 24 pixels, or 5.33 per 8 pixels. That's enough to read one tile number and one 4-bit sliver, but no attributes. Does it just skip attribute fetches and hardcode the 16 color values to $00-$0F?

After rereading the VT03 datasheet, it looks like I was wrong, and it's picking different bus speeds depending on whether the PPU is using 2/4 bpp tiles/sprites.

I came up with speculation for how the chip works.

For every 32 pixels, there are 11 CPU cycles, 1 attribute byte, 4 name table bytes, and 16 pattern table bytes read.

According to the VT03 documentation PDF, the XRC 1 mode palette is divided into four 12x2 entry regions (plus mirrored transparent #0) across 3F00-3F7F, combined with parallel 3F80-3FFF for 12 bits per entry (4 bits per L, S and H). (3,500 color selection?) Up to 121 colors can be represented at once in this mode versus the classic 25.

In this mode, color attributes fall into larger regions in the palette, not larger character regions (background is always 16x16 per 2-bit attribute). Bit #5 of a sprite's attribute byte allows access to background colors. There's still the limit of 8 sprites per line, but low-color sprites can be 16 pixels in width.

SMB3 would look more like the All Stars version with this kind of bit depth improvement.