This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

MMC5 with CHR-RAM

MMC5 with CHR-RAM
by on (#175271)
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?
Re: MMC5 with CHR-RAM
by on (#175503)
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?
Re: MMC5 with CHR-RAM
by on (#175504)
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.
Re: MMC5 with CHR-RAM
by on (#175505)
hellfire wrote:
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?

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.
Re: MMC5 with CHR-RAM
by on (#175517)
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.
Re: MMC5 with CHR-RAM
by on (#175579)
Disch wrote:
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.
Re: MMC5 with CHR-RAM
by on (#175754)
rainwarrior wrote:
I think the implementation is just a consequence of the original iNES format not having a way to specify CHR-RAM size, and the lack of extant MMC5 games using CHR-RAM.
Almost any mapper should be able to substitute CHR-RAM for CHR-ROM.

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.
Re: MMC5 with CHR-RAM
by on (#175787)
Would a real MMC5 board route the write pins correctly to CHR-RAM?
Re: MMC5 with CHR-RAM
by on (#175800)
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.
Re: MMC5 with CHR-RAM
by on (#175807)
Fortunately, you're mistaken; PPU /WR is present on (at least) my NES-ELROM-01, because that connects to MMC5 pin 33.
Re: MMC5 with CHR-RAM
by on (#175810)
And what does the MMC5 do with that signal?
Re: MMC5 with CHR-RAM
by on (#175811)
I'd guess it's for handling writes to the 3rd nametable via the PPU's bus.
Re: MMC5 with CHR-RAM
by on (#175814)
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?
Re: MMC5 with CHR-RAM
by on (#175845)
tepples wrote:
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?
Re: MMC5 with CHR-RAM
by on (#175849)
Write 8K, write to bank regs, write 8K more... Videomation manages it.
Re: MMC5 with CHR-RAM
by on (#175948)
tepples wrote:
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).
Re: MMC5 with CHR-RAM
by on (#175950)
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.
Re: MMC5 with CHR-RAM
by on (#175972)
hellfire wrote:
tepples wrote:
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...

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.
Re: MMC5 with CHR-RAM
by on (#175979)
Quietust wrote:
Not sure what you're talking about - I just tested Videomation in Nintendulator and it worked just fine.

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 ;)