MMC5 with CHR-RAM

Hi everyone!

I'm just twiddling with some demo effects using a 16x16 tile set which is updated using chr-ram during the empty screen areas.

I'm currently trying to move this from an MMC3 mapper to MMC5 (because I need some more PRG-RAM and the extended attribute data).
But I can't get anything into CHR-RAM yet.
What I've done is to change byte 6 (mapper id) from $40 to $50.
Nametable0 ($2000) and CHR-RAM ($0000) are filled just like before.
When I use CHR-ROM instead (by changing byte 5 in the header), I can see my (constant) nametable.
I'm testing with Nintendulator, Nestopia and a PAL NES with Everdrive N8.

So what's the trick to write to CHR-RAM?

Ok, had a closer look into the Nintendulator source code and there's absolutely no support for CHR-RAM for MMC5...
Is there a reason why it would be impossible to connect CHR-RAM to the MMC5?

Emulators (and flash cart mappers) often implement only a subset of features that are used by commercial games. (Support for more than 8 KB of CHR-RAM was also a feature that was missing for a long time in many emulators.)

There's no intrinsic reason why CHR-RAM couldn't be used with MMC5.

I don't think there's a "reason", I think the implementation is just a consequence of the original iNES format not having a way to specify CHR-RAM size (amended in a more recent revision of the format), and the lack of extant MMC5 games using CHR-RAM.

Almost any mapper should be able to substitute CHR-RAM for CHR-ROM.

Somewhat related:

One thing that always confused me about MMC5... when using 8x16 sprites there is 12K of CHR used for rendering, but only 8K of addressing space in PPU memory. We all know how this works in rendering (sprites use front 8K, BG uses back 4K) -- but what about software access via $2007?

Would $2007 reads/writes access only the sprite patterns? Or would it depend on something else?

This seems like a detail you'd need to figure out if you want CHR-RAM on MMC5 ... since you'd need to know what CHR you're writing to.

It is a detail I would want even if it is not CHR-RAM, because we should need to know all of the detail needed for correct implementation, even if they are features that are not currently used by anything.

Well, I somehow expected the Everdrive could handle CHR-RAM as it already works on RAM anyway. Too optimistic, of course. Even seems like they just ripped off the existing mapper code (which makes perfectly sense when they just want to get the games running).

Too bad a lot of hardware potential just lies to waste now.
So, basically we have to wire some RAM to an actual MMC5, check how it behaves and update the mapper code for Nintendulator and the Everdrive/Powerpak...
That's probably too much of a quest for me right now. So I'll stick with the MMC3 for some longer.

Would a real MMC5 board route the write pins correctly to CHR-RAM?

Not a stock board. Early NES games had all 72 contacts on the Game Pak edge connector. Later board revisions removed unused contacts, such as the unused expansion pins in the middle and the PPU /WR pin on CHR ROM boards, presumably to save money on gold-plating them. This is why some repro makers prefer Super Mario Bros. 2 when making translated Final Fantasy III: it's one of the few NES games with MMC3 and WRAM published before Nintendo made this change. By the MMC5 era, Nintendo had already been leaving these pins off the board, meaning the PPU /WR pin on the 72-pin connector touches the PCB's substrate, not a contact.

(EA did the same thing on its Genesis games. This worried me when I bought a used loose BlockOut at a pawn shop, as most of the unused pins were on one side of the edge connector, making me think the cart may be damaged. Fortunately, it worked in my Genesis 3.)

As for a modified board, you'll have to ask someone who has made a repro of Rockman 4 Minus Infinity.

Fortunately, you're mistaken; PPU /WR is present on (at least) my NES-ELROM-01, because that connects to MMC5 pin 33.

And what does the MMC5 do with that signal?

I'd guess it's for handling writes to the 3rd nametable via the PPU's bus.

Thanks for the clarification about the possibility of writing to ExRAM through the PPU.

In that case, bending up your CHR RAM's /WE and connecting it to MMC5 pin 33 should allow it to work. Is a test ROM needed? How big is the CHR RAM that you plan to use: 8Kx8 or 32Kx8?

How would you write more than 8kB into PPU_DATA when the nametables start at $2000?

Write 8K, write to bank regs, write 8K more... Videomation manages it.

Fancy, never heard of that one! It's also not emulated correctly because Nintendulator mirrors CHR RAM after 8kB...
However, it's using mapper 13 which explicitly supports CHR RAM bank switching. Haven't seen anything alike on MMC5 yet (might just be an undocumented features, though).

Mappers like these don't support CHR RAM bank switching as much as CHR bank switching in general. "Bank switching" just means driving upper address lines, and the mapper doesn't care whether the memory to which the address lines are connected is writable.

Not sure what you're talking about - I just tested Videomation in Nintendulator and it worked just fine.

Nintendulator doesn't "mirror CHR RAM after 8KB" - most of its mappers simply don't map more than 8KB of RAM because that's all that most of them have. Notable exceptions include mapper 13 (Videomation, 16KB), 19 (Namcot 106, 32KB), 28 (Action 53, 32KB), 96 (Oeka Kids, 32KB), and 11/16/66/85 which use banked CHR RAM in the absence of CHR ROM and obey the NES 2.0 header to determine how much RAM is available.

You're right, my fault - had it running in PAL mode so the timing was wrong and bankswitching happened at completely wrong positions.
Mirroring seems to happen only for header version 1 ("iNES_SetCHR_Auto1" in d_iNES.cpp). Thought I had seen it elsewhere but I was probably just confused again