nesdev.com

MMC5 supports CHR RAM, though no existing cart board came with CHR RAM. You'd have to modify a board to take CHR ROM, just as you'd have to modify cart boards to take flash memory for PRG ROM.

Currently there's no CPLD clone of MMC5, so think about that if you're seeking cart manufacturing.

For "constant upload of data to video RAM", look at what's going on in Haunted: Halloween '85. The demo is part of the forthcoming third volume of Action 53.

Sure, the two players are both sprites, but you don't have to always use sprites for enemies or objects! You can use the playfield quite effectively for:

Stationary objects - like the coins in SMB and SMB3. Unless you're using MMC5's extended attributes, you're limited to one playfield palette for every 16x16 metatile, and that's one reason why the coins are as big as they are. The coin palette is also used for other parts of the level, like breakable blocks and question mark blocks.

Stationary enemies - if the enemy scrolls with the level and doesn't otherwise move.

Boss fights - to have a really crazy boss fight with tons of objects on screen, many games would make the boss itself out of playfield tiles, and scroll the screen to make the enemy move. The Guts Man fight in Mega Man 2 and the Technodrome fight in TMNT both come to mind. Since the boss is the playfield, the rest of the screen is just the background color, but that never seemed to bother anyone.

Technodrome is a terrible name.

drome means "racetrack" or running. This thing moves slowly. In no sense is it racing.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

I'm not up on TMNT lore, but my first handwave would be that it used to be a racetrack for a traveling cyclesport exhibition before Shredder bought it to convert it to a mobile fortress.

I wonder if it was named in reference to Videodrome, the excellent David Cronenberg sci-fi body horror film? And I think "videodrome" itself is supposed to be a portmanteau of "video" and "syndrome".

I just quote you because I agree Also the 8-sprites per line limitation make it difficult to overlay sprites without running into problems.

As for answering the original question, my opinion is that 1 palette for player 1, 1 palette for player 2 and 2 palettes for enemies is the very standard way to do it (assuming a 2-player co-op game). If you need the palette to change to reflect player's state there's not much else you can do. The only thing you can do is change the enemy's 2 palettes during the level.

Just Breed has a system where it loads the sprite palette dynamically in function of what it needs to draw, every frame. As far as I know this is unique. It also uses some sprite overlay for the hero, meaning the first 2 palettes are "fixed" and only the last 2 variable (dynamically loaded).

Another very simple "trick" is to have a constant sprite palette across the whole game. It might sound like it's not a very advanced technique, but it works wonders for Castlevania and Battletoads&Double Dragon for example. Since you know what colour palette you have at all times, you can reflect state changes of the player by changing them, and any enemy can use all 4 palettes freely. Battletoads on the other hands has only the 4th palette which is variable.

One thing that might help in a co-op game is not making your player 1 and player 2 characters palette swaps of each other. That way they can use the same palette, and you can justify their being the same color as a uniform or whatever. But I'd need to see your character designs in order to tell whether that's plausible for your project.

Or: Make them palette swaps in the way that you save their tiles twice in memory, only that one character uses a red shirt and blue pants while the other one uses a blue shirt and red pants.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg

That was one of the things that surprised me when I started looking into NES.

Like flashing/changing one sprite's palette different colours to show damage states etc. seems like such a common / obvious / easy technique on most other systems I'm familiar with, but on NES when it happens it's usually designed very specially around it. Maybe having several versions of the sprite in CHR for different rotations of the colour, or reusing one of the existing palettes instead, or if it's a "background" sprite using attributes instead of changing the palette itself. I did not expect all these work-arounds before I got to know the NES.