Extending the Action 53 mapper

The Action 53 mapper is an ASIC mapper of roughly MMC1-class complexity, implemented on CPLD cartridges sold by Infinite NES Lives. It was originally designed for making multicarts of games using common discrete mappers (NROM, CNROM, UNROM, ANROM, BNROM). It can also be used by a single game that takes full control of the mapper to switch both PRG ROM and CHR RAM banks at runtime by changing register select at CPU $5000. Its division of register numbers into "supervisor" and "user" registers anticipated games using full control, but with one caveat: switching between horizontal and vertical mirroring requires a supervisor write, as does initialization at startup.

But now people want to make games using its advanced features and get them included on a multicart. This is possible with a 1-byte patch so long as the game never changes the outer bank register ($81) after startup and always writes the correct log(prgsize/32768) value to bits 5-4 of the mode register ($80).

In this post, INL suggested developing an extended discrete mapper that allows switching PRG, CHR, and mirroring without having to write to supervisor registers $80 and $81 or even to register select. I proposed basing it on mapper 78, variants of which are used by IREM's Holy Diver (78.3) and Uchuusen: Cosmo Carrier (78.1), and making it tweakable using the mode register to resemble mapper 11 used by Color Dreams games. Thus an additional user mode of an expanded Action 53 mapper would have this layout at $8000-$FFFF:

The inversion is there because the sense of bit 3 on the Holy Diver board is like that of the iNES header (0=PA11, 1=PA10), which is inverted compared to that of FDS, MMC1-4, VRC2/4/7, FME-7, and both Action 52 and Action 53 (0=PA10, 1=PA11).

How this would work:

• 32K PRG banks
  Similar to mapper 11, except with mapper-controlled mirroring (either H/V or 1-screen) instead of CIC stun control. (Only two commercial-era games using this mapper have horizontal mirroring; the rest have vertical mirroring.) This allows accessing all four CHR RAM banks and the entirety of a 256 KiB outer bank.
• 16K PRG banks, game up to 128 KiB
  This behaves like either variant of mapper 78, except CHR RAM is limited to 32 KiB.
• 16K PRG banks, 256 KiB
  Because there are only three PRG ROM bank select bits, a game needs to select UNROM (write $01 to $5000), change bit 3 of the inner bank number, and select mapper 78 again. But as long as the game doesn't need to change between 16K and 32K modes or between H/V and 1-screen mirroring, this eliminates the need to write to supervisor registers after startup.

INL's counterproposal was to add a mode equivalent to MMC3. He pointed out that the cost of doing so is negligible given all the 5.0 V to 3.3 V level shifting needed to use a PRG ROM larger than 4 Mbit (512Kx8). This would behave similarly to TGROM (Mega Man 4; Mega Man 6; Ninja Crusaders) and the expanded TGROM used by The Curse of Possum Hollow, which would in theory let Retrotainment submit the demo of Curse as a free-for-all in volume 4.

In the general case, that would be 1 byte patched per 32KiB of PRG used. [Worse if inefficiently-coded, of course, but that would be preventable by having official subroutines for bankswitch and modeswitch.]

While I think your proposal would work Tepples, the thing it appears to lack is ability to change between 16KB and 32KB PRG-ROM bankswitching. I don't see how it helps basing directly off the other mappers when emulators don't support CHR-RAM for mapper 11.

There are a couple problems that we're looking to solve here:
1- Allow compo entries access extra hardware available on cartridge. At a minimum this includes bank switched 32KB CHR-RAM, and selectable mirroring.
2- Simplify the mapper requirement for the compo beyond 'mapper 28' compatible, which is hard to translate to entrant's mapper choices.

My first proposal of a new discrete mapper similar to Tepples' proposal is an option, but it then creates a new problem that development tools (emulators) don't support this new mapper. Sure support could be added to FCEUX, but it's unlikely to be a fast nor simple process.

Last compo we exceeded 4mbit of data which is the threshold for which 5v parallel memory can be purchased cost effectively. Going past 4mbit makes 3v memory the only viable solution, and once we've done that, we've now unlocked a 3v CPLD/mapper with ~200 cells. Doing that, allows the compo mapper access to MMC3 scale logic at no additional cost. The added cost was paid when we jumped from 4mbit to 8mbit rom.

So with that, perhaps the best solution is we simply add MMC3 to the list of available mappers for compo entrants. Any emulator that supports nes 2.0 will allow development with 32KB CHR-RAM. Altenatively CHR-ROM could be utilized which is supported by nearly all emus. This also provides significantly more mapper features to entries, I'm not sure if this would be good or not. Some may feel they didn't adequately make use of available hardware, or that things aren't on quite the same level playing field between entries that do and don't utilize the MMC3.

I don't know how this proposal would affect the menu's responsiblity/challenges. Initially I expected use of MMC3 might promote less efficient use of rom. But MMC3's increased bank granulatity might actually help keep entries condensed.

So I'm still not sure what the best answer is exactly. Maybe the current setup is best, and we're proposing repairs to something that's not broken after all. Curious what compo entrants think about all this...

I was under the impression that the banking style would remain constant throughout a game.

• 32K: Use mapper 11. This is BNROM with CHR RAM banking; it does not support mapper-controlled mirroring or switching to 16K.
• 16K: Use mapper 78.1 for 1-screen mirroring or mapper 78.3 for mapper-switchable H/V mirroring. It doesn't support switching between H/V on the one hand and 1-screen on the other or switching to 32K.

I'll take that as a feature request for adding mapper 11 to that test ROM you commissioned, which already supported mapper 78.3 from the start. This way someone with a soldering iron, a Color Dreams cartridge, a spare flash or UV EPROM, spare 32Kx8 SRAM (e.g. 62256), and a CIC modded NES could flash Holy Mapperel and verify that the combination of 64K of PRG ROM, 32K of CHR ROM, and mapper 11 is valid. (The CIC modification is necessary because my demo would lack a charge pump control routine. It wouldn't be needed for a Sunday Funday reprint donor.) Then we should know whom to bug.

I grant that both a brand new discrete mapper and support for CHR RAM in mappers 11 and 78 would require changes to at least one emulator. But I conjecture that support for CHR RAM in mappers 11 and 78 requires smaller changes to fewer emulators than a brand new discrete mapper.


That'd require a bit of thinking to figure out how to best handle both discretes and full MMC3.


And any emulator that doesn't support MMC3 + NES 2.0 can't run a demo of The Curse of Possum Hollow should Retrotainment release one. But it's one thing to make an emulator support MMC3 and NES 2.0; it's quite another to make it support a multicart mapper covering both MMC3 and the discretes. Or is there a suitable ready-made MMC3+discrete mapper in one of the pirate multis?


You might level this by slightly modifying the prize structure to include both a discrete winner and an MMC3 winner.


As long as the mapper can switch between MMC3 and discrete modes, there wouldn't be much of a need for that. Currently it runs in the same oversize BNROM mode it ran in since before mapper 28 existed, only switching to the particular game's preferred mode before jumping to it. The menu would just need some flag to tell which games are MMC3.

COOLBOY, for one.

Yes it likely would remain constant. But again, emulators already don't support your proposed configs. My original idea was that since emulator support would have to be written in, we would make one concise mapper definition that met feature goals, and gave one mapper number for the compo rules to point to. It should be clear if an emulator support this brand new mapper or not, instead of some non-standard extension off mapper #11 etc. To permit both 16KB and 32KB banking it could simply be built into the new single mapper definition (similar to MMC1).

Yeah IDK, the whole idea is becoming a bit of a mess. Starting to think entries simply need to wrap their head around mapper28 supervisor registers if they want these features. I'm not the one that would be modifing emulators, so I have no real authority on what's best other than it's often best to avoid creating new mappers if possible.

Good point, I hadn't thought about that. Even more reason to axe the MMC3 idea.

Maybe, but we've found that separate categories doesn't work so well in the past.

Which don't?


The test ROM, built from the latest commit to Holy Mapperel, is attached.

I'm currently seeing a problem with 78.3 in FCEUX, but it appears to be unrelated.

oh! my bad, I shouldn't have assumed they didn't support mapper 11 with banked CHR-RAM. I take it, mapper 78 with CHR-RAM is supported as well?

In that case, sounds like I'm making a big deal about nothing then.

I'll test for that once I finish bugging emulator authors about another mapper 78-related issue.