Mapper 245 repros?

Hey everyone,

I've got a friend who's super into the Destiny of an Emperor series and wants me to make him a cart of The Rise of Lu Bu. The only problem is that the hack changes the mapper from a typical SNROM board to a Chinese mapper. Would it be possible to modify a TNROM board to support the game?

You might be able to just rework an MMC3 as:

Disconnect MMC3 PPU A10,A11,A12 IN, tie all three to ground. Disconnect MMC3 CIRAM A10 OUT from CIRAM A10 IN, tie CIRAM A10 IN to PPU A10 (vertical mirroring / horizontal layout). Disconnect MMC3 CHR A10, A11, A12 OUT; connect CHR RAM A10, A11, A12 directly to PPU A10, A11, A12. Connect MMC3 A11 OUT to PRG ROM A19.

(Reference: http://wiki.nesdev.com/w/index.php/MMC3_pinout )

But I don't know.


ALTERNATIVELY, the choice of mapper 245 looks strongly like this (is yet another thing that) really just wants oversize UNROM with PRG RAM. Try this patch.

This patch WILL NOT work in FCEUX, because of a hilariously awful "bug" fix they committed a while ago.

edit: apparently it only works in Nestopia. Maybe fishy...

I couldn't find any space to add a bus-conflict prevention table, so I've instead marked the header with submapper 1 for "do not enforce bus conflicts". If you play through a bit in an emulator, and find that it's no buggier than without my mapper hack, to make the hardware reproduction you will need to add an inverter (74'04, 74'00, 74'02, whatever) to the board to convert R/W from the NES into /OE for the PRG ROM.

An easy way to do is to use two 74'02s instead of two 74'32s, and reverse the 16 KiB slices in the image that you burn onto the 'PROM; this will leave you with two spare NOR gates, one of which can be used to prevent bus conflicts as above.

(I did set it up to write the requested bank to a byte which is "$FF" in the PRG ROM, so normal AND bus conflict behavior "should" produce the right value... still).

Hashes to verify correctness:

Wow! I was not expecting that much help (or such a large solution). The second option sounds like my best bet, but reworking a UNROM board like that (adding SRAM, etc) is way over my head at this point. Do you have any good resources where I can read about modifying boards or is the nesdev wiki my best bet?

Thanks again, you rock!

UNROM first:
The physically easiest way to add RAM to an existing board is to piggy-back it on top of or under the ROM. And http://wiki.nesdev.com/w/index.php/PRG_RAM_circuit
I'd strongly recommend (if you can get an 8KiB RAM rather than a larger one) using a power fail protection circuit like this one.
If you're modifying an existing UOROM board, you'll need another 74'161 and a (74'02 or 74'32-plus-inverter). You also can't buy new DIP 'PROMs that are larger than 512 KiB, but you can still get new-old-stock and salvaged ones.

TxROM boards:
The MMC3 is a relatively large IC as far as surface mount things go, but if this is your first "real" practice with soldering, I'd recommend getting someone to help you, or at least putting in a bunch of hours(sorry) of practice first. Cutting traces, using very fine wire, and a fine tip on the iron will be easier ... unless you have access to a hot air rework system.

Note that his hack only changes the m245 outer bank by writing to MMC3 indirect register 0 (i.e. [$8000]←00, [$8001]←outer bank). I don't know if this is what the actual hardware does, because we don't have any actual m245 games to look at. Certainly it's compatible with FCEUX's implementation of MMC3, which (unfortunately) pretends all of MMC3's indirect registers 0-5 are the same.

It seems unlikely to me that that is how the actual m245 board works because disconnecting PPU A12 from the MMC3 disables the MMC3's IRQ capability, and why would you do that? On the other hand, Nestopia's implementation of m245 ONLY maps the outer bank register to indirect register 0.

Cool mapper hack, lidnariq! But would it be possible to port it to MMC1 instead? I'm thinking something like SXROM, with the higher address lines of the CHR ROM connected to the PRG ROM? SNROM donors are plentiful and making the necessary modifications to such a board would be trivial compared to hooking up SRAM and a battery to an UNROM-board.

The author removed the lower SNROM semi-fixed bank (UNROM/MMC1 bank $F, file offset 0x3C010-0x4000F), and (re-)adding semi-fixed banks is a much bigger pain, so whatever mapper hack is basically going to require 512KiB inner banks.

All in all ... that's a much larger endeavor, and I wouldn't find it fun or interesting. The mapper hack from m245 to UxROM was really simple (see the size of the ips).

Thinking about it briefly, disabling or removing the MMC1 and dead-bug-ing on a 74'377, two 74'32s, and a 74'20 is not unreasonable...

The game was originally SNROM; the author expanded it to SUROM w/ version 2.0; and for version 3.0 they wanted something Even Bigger, and there are very few official mappers that support more than 512 KiB of PRG.

Basically the only things left are: UxROM, MMC5, the various Waixing MMC3 clones with internal CHR RAM (m74, m191, m192, m194, m195), the JY company mappers (m90, m209, m211), the pirate MMC3 multicarts (m44, m45, m52, m245), and Tepples's multicart mapper.

Interesting idea! Modifying SNROM-board to become an UNROM-board with battery backed SRAM would be a lot less work than trying to modify an UNROM-board directly!

Hypothetically though, would it take a lot of work to port it to the MMC5 mapper instead?

No, an MMC5 port should be equally easy, but MMC5 donors are rare, and none come with CHR-RAM.
---

Actually, you could probably keep the MMC1's PRG RAM decoder and skip the 74'20, as long as your donor has an MMC1A or MMC1B.

Yeah, NES MMC5 donors are rare, but Famicom MMC5 donors are surprisingly cheap!