[POC] Expand MMC3s Addressbus to allow 1MB PRG on real HW

First off: Hello nesdev community! I have used the wiki and read many posts here which greatly helped understandindg the way an NES/Famicom works. Now I want to give something back, whether it be useful or not.

This is a Proof of Concept on expanding the MMC3s Addressbus by one Bit, so it can address an actual 1MB of PRG data, or 128 Banks. I saw a post here which assigned TXROM type to a PCB, which does support 2MB of ROM data, but it doesnt have true Bank support for more than 64 Banks, it just writes to some latch which controls ROM lines and a switch to switch in a game that has 512kB PRG max.
The reason why I did this was because I got stuck in another project, and I kind of got carried away when I thought it would be awesome to play some MegaMan Minus Infinity on real Hardware without chopping up the rare MMC5 NES cartridges (I might have gotten myself a Famicom version of an MMC5 cart with an adapter, but that would have cut out the fun and INL Boards dont seem to support either MMC3 with 1MB PRG nor MMC5 at all).
My circuit consists of "only" 10 discrete Logic ICs, this can actually be cut by a bunch of ICs (I used stuff laying around, which resulted in using NAND gates to get a simple NOT and stuff like that increasing the number of used ICs). Essential were 2 FlipFlops, a Latch, 2 demultiplexer for Address access, an OR-Gate, and a bunch of AND-Gates.
For now I have only the Logic signals to show off which i captured to debug everything, it should be enough to see if the circuit is doing its work or not. It would be helpful if somebody could verify it, i couldnt see any malfunction.
The code used to test the circuit:
Picture A:


Picture B:

Note: $8000, $A000, $C000, $E000 show the access (so Read and Write) to the specific Address area (8kB Bank). RA19 would be connected to PRG ROMs A19. the first time $8000 is pulled High on the pictures is the first "sta $8000" instruction. The whole code is executed from $E000-$FFFF, so reads from $E000-$FFFF always pull RA19 high, resulting in the last Bank always being switched in.

I have yet to draw an exact schematic for everything, and test it with the actual game (I ordered the proper parts already).

That is one mess of wires.

For that much money you could probably buy a pair of CPLDs that implements the whole MMC3, or perhaps enough of a subset of the MMC5 to run the Mega Man hack.

I guess this is true, i recently looked for 5V tolerant CPLDs and saw some from atmel which cost about 1,50€ a piece. I will probably go for one of those to implement at least the extra logic involved. but for anyone interested in what logic is involved, i will post a schematic.

I don't want to burst your bubble, but ... you really shouldn't need 10 ICs for this.

74'138: decode /WR8000 and /WR8001
74'161: latch /WR8000 bits 0,1,2 and 6
74'138: decode /WR8001_6 or /WR8001_7 when /WR8001 and latch8000&7=6 or 7
74'74: each half latches /WR8001 bit 6 when /WR8001_6 or /WR8001_7
74'151: use latch8000&64, CPU A14, CPU A13 to select between latch8001_6, latch8001_7, and 1 as appropriate.

Or use a single Greenpak. The above will fit in anything with enough I/O (A14_in,A13_in,A0_in,/ROMSEL,W/R,D0,D1,D2,D6,A19_out)

@ lidnariq
No need for Phi2?

Not when solely increasing the size of PRG. M2 is only needed for 1- when something is mapped between $4020 and $7FFF or 2- when as a clock source.

Yes, you are right.
/ROMSEL is the logical NAND of Phi2 and CPU A15, so when /ROMSEL is 0, A15 and Phi2 are 1 certainly :

I think 74 way is more expensive than cpld.

10x 74hc74 @ 0.09$/
10x 74hc161 @ 0.15$/
20x 74hc138 @ 0.11$/
10x 74hc151 @ 0.15$/
total: 10x for $0.50/

Almost all of these from rocelec.com

I mean, you're probably better off recreating an oversize MMC3 equivalent in CPLDs, like INL's board, but for the limited sense of "you already have an MMC3 and you want to add something to it", the price here is quite defensible, even compared to a GreenPak.

@OP

forgive the off-topicness, but, what logic analyzer are you using to generate the pics above? Has it worked well for nes stuff like this?

ot: is there a specific cpld recommended over the 74's?

The cheapest one right now is Xilinx's XC9500XL series, but scuttlebutt has it that they're going to discontinue it in a few years.

I guess you can also get 22V10s as NOS from a bunch of suppliers too, that might be a reasonable decision.

Lattice and Atmel still sell some 5V CPLDs, but they're expensive enough to make it no longer the obvious best choice.

Since I keep on talking about Silego's GreenPAKs, I figure I may as well share this proof-of-concept for implementation on that hardware. I'm shy by one latch or 3-LUT from being able to fit a full 2MiB oversize support, so instead I used the extra I/O lines to let you jumper which of the two PRG banking registers is 8 bits instead of 7. Or you can just add an external 74'74 and get both.

I specifically chose the SLG46721V GreenPAK3 for this. Here's what it looks like in the designer:You can basically string together the set of latches, 2-,3-,or 4- input lookup tables, and a few other things (mostly mixed-signal) that I haven't yet figured out what to do with yet.

And here's the actual designer and fusemap data:

Of course, since the designer tool doesn't do any optimization for you, there's lots of room for golf. For example, I figured out how to free up a latch to finish expanding support to 2MB:

As I understand it, the behavior is as follows:

• $E000 is always bank 255
• Either $C000 or $8000, depending on bit 6 of $8000, is always bank 254
• Bank registers 6 and 7 can be set from 0 to 255

Do I understand the behavior correctly? And if so, would it be wise to add this to the definition of mapper 4 going forward? I can think of some future Retrotainment Games projects that might benefit from an MMC3 with 1 or 2 MiB PRG ROM and 32 KiB CHR RAM.

So, the original reason for limiting mapper 4 to strictly 512KiB and smaller PRG was that the hardware for that oversize variant did not exist. Enforcing a hard cap on the size was a way to prevent ROM hackers (because, let's be honest, that was the use case) from depending on hardware that didn't exist.

With both this GreenPAK solution and the discrete logic solution, it's clear that that reason isn't trivially true.

Nonetheless, adding this extra hardware is still mechanically hard and still requires donors. Furthermore, new larger-than-512KiB PROMs only come in surface mount packages, and 5V larger-than-512KiB PROMs are conspicuously more expensive. (~3$/ROM instead of ~$1.6)

Much as when I helped persuade you to invent mapper 28 instead of defining an oversize MMC1 extension, I'd again prefer the creation of a new mapper that better represents the interests of developers looking for MMC3-class hardware than just using an oversize MMC3. IMO, something shaped like Namco's 340 plus MMC3 IRQs would be a better candidate.