Is it possible to add new colors to the palette?

Say you want a shade of red that is simply not on the predetermined 64-color palette of the NES. Would it be possible to create new colors for the PPU to display? I assume this would be done, if possible, through the use of custom-made mappers.



Or are mappers ONLY for supplying additional RAM to the CPU and APU?

Mappers on the NES do two things: memory paging and interval timing. The "paging" part makes additional ROM or RAM available to the CPU and PPU, and "interval timing" is used to notify the CPU that the electron beam has reached a particular point down the screen. That's why Nintendo's ASIC mappers are called "Memory Management Controller" (MMC). Even the mighty MMC5's ExGrafix mode is just an extremely fine-grained CHR ROM mapper, specifying a 4K bank number for each tile.

You can tint the entire screen using the emphasis bits in $2001. A mapper's interval timer may help you build a raster effect that tints one strip of scanlines different from another strip. But apart from that, mappers can't affect the palette. That's why the color bar test cards in the NES port of the 240p test suite aren't exact matches for the 75% intensity pure colors on the SMPTE EG 1-1990 test card.

You can only customize the palette if you change the PPU, or attach some extra hardware to it (e.g. NESRGB and Hi-Def NES), which means the console has to be modified. It can't possibly be done from the cartridge side, because the cartridge is not at all involved with color generation, so there're no signals related to this in the cartridge connector.

The only way you'd be able to change video characteristics that depend on more than external memory access is if you put a custom video chip inside the cartridge and connect a cable from that to the TV, instead of using the console's video jack. Most would consider this cheating though, since you could just as well put an entire 3DS inside the cartridge and use the NES just for input, meaning games wouldn't be running on the NES at all. Needless to say, it would not be economically viable to sell cartridges containing entire video systems (or more modern gaming systems!) in them, not to mention the time you'd spend developing your own video chip.

Oh, wait, that gives me the most terrible idea! We could intentionally cause voltage sag by drawing huge amounts of power on the cartridge. This would couple back into the video signal and allow us to change the color of things.

And we should never ever do it, because one'd have to calibrate it on every different console you wanted to use, and some consoles would never work anyway.

The calibration screen should be interesting... "Press A until the picture looks correct OR your NES explodes"

That's what I call "gaming on the edge".

Ha, I just saw several of those a few days ago. Carts for the SNES and NES that take input and power from there, but have their own video output, and play $ANOTHER_CONSOLE's games.

What about the port underneath?

Well, you could add an arbitrary video overlay system via the expansion port, but I'm not really clear to what end. You don't have access to any other PPU signals, so you can't trivially lock to the same pixel clock.

I never noticed that there was a video out pin in the expansion port... Not that I can see any advantage in getting the composite video from there rather than from the back of the console... I mean, even if you were gonna pull a 32X you'd still need the add-on to output its own video signal, so it might just as well generate something advanced enough that doesn't require any of the blurry video from the PPU.

In theory, composite out (pin 21) and master clock are all you need. The PPU outputs one dot of picture or blanking every 4 master clocks (5 on PAL), it outputs vertical sync every vblank, and it outputs horizontal sync and a "color burst" (dark area with hue $08) before every line. But the real WTF is that there's no master clock on the expansion port.

Why? The cartridge can easily route it to an expansion pin.

Or, devices like the Hi-Def NES could be modified/designed to allow for software to detect that they are installed and ask to modify the palette. But this would be a pretty specific target market ...

Well, the biggest advantage would be that you wouldn't need a passthrough cable which would look cleaner as well as being less prone to get connected wrong by a clueless or distracted person. The 32X needed a passthrough cable in addition to changing where the video output goes.

That reminds me of how Shantae for the Game Boy Color had special features when used on a Game Boy Advance. Maybe there could be some backwards compatibility between the vanilla NES and the Hi-Def NES in the same manner.

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.

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.