nesdev.org

3GenGames recently made an MMC1 based multicart engine. The biggest thing it does that my own engine doesn't is the mirroring switch, which MMC1 can do but #34 (oversize BNROM) can't. On #nesdev, we got to discussing how I could port Action 53 to MMC1. Testing such a port would need emulator support because there aren't any existing MMC1 boards over 512 KiB, nor does the PowerPak support such an oversized PRG ROM. And in any case, we'd first need to define an extension to the MMC1 to handle PRG ROM larger than 512 KiB for emulator and PCB makers to implement. Because of how existing PRG ROM select bits are arranged in existing MMC1 cartridge boards, this is tougher than the "obvious" oversize extensions to many of the discrete mappers.

SNROM, SOROM, SUROM, and SXROM reuse unused bits of the CHR bank address as follows: How should PRG ROM bigger than 512 KiB work? Would the bank bits be added in reverse order like in mapper 87? That would look like this:

Why should a larger-than-512kB game be a functional superset of SUROM as opposed to anything else? If you do want a super-SUROM, why not use the never-before-seen-used bit 1 for A19?

Is there any reason to leave both CHR banks enabled and not tie the mapper's A12 input low, freeing up all 5 bits for other purposes? i.e. has anyone had reason to switch both 4kB slices of CHR RAM to the same half?

As far as I can tell, there isn't really a reason not to do both. Is there any reason to support banked PRG RAM? Otherwise I'd just allocate all 5 bits in normal ascending order, even it it implies support for things much bigger than iNES1 can support.

Inspired by Munghausen

Is there any reason to support banked PRG RAM?

to keep saves separate.

SNROM, SOROM, SUROM, and SXROM

sounds like list of donors

How should PRG ROM bigger than 512 KiB work? Would the bank bits be added in reverse order like in mapper 87? That would look like this:

Whatever reduce calculations on software side is good.

Am I the only one tired by this endless super mapper talk ?

What's the problem? No one forces anyone to read all forum threads.

There is no problem really - I was just pointing out to tepples that such discussion have already been made 3918 times on these boards and that they hardly bring anything new.

Where was the specific discussion on how to interpret an MMC1 image larger than 524288 bytes? I already used the forum search to look for oversize mmc1 but found no relevant posts. That and kevtris likes to remind #nesdev of how cheap a large flash chip is.

EDIT: qwertymodo agrees that big flash memories are cheap as chips: "$2 each for the 32Mbit chip".

tepples wrote:Where was the specific discussion on how to interpret an MMC1 image larger than 524288 bytes? I already used the forum search to look for oversize mmc1 but found no relevant posts. That and kevtris likes to remind #nesdev of how cheap a large flash chip is.

Good thing

EDIT: qwertymodo agrees that big flash memories are cheap as chips: "$2 each for the 32Mbit chip".

Don't forget to add 3.3V regulator and a bunch of resistors. Otherwise all good.

I'm guessing some of this might be motivated by thefox's efforts with streemerz and it's current/potential use MMC1.

Your proposal seems logical to me. I'm more than willing to help out with hardware testing if/when you get to the point that it becomes useful.

My thoughts: I'd question if sticking with the MMC1 is really worth it since the mapper isn't already supported wired up as is. Seems like it'd be simpler to just add mirroring select and such with your BNROM setup as we're discussed before. The only real benefit of MMC1 is that it has relatively low pin-count and the IC exists in donor boards. However the pin-count is a non issue really for discrete/cpld solutions so really you're only supporting the destruction of original carts.

That's actually a very good point, infiniteneslives. Once you have to add emulator support, even if it's defining a new variant, you may as well define something that's a better match (e.g. cheaper)... for example, a variant of AxROM which used the top 4 bits as the input to a 74'153 and allowed you to choose any mirroring format. (Or only use two bits of the latch and wire it differently to provide 1ScA/1ScB/H/V only, in which case it could be backwards compatible)

People need to get over the fact you're using original parts from games. It's so much cheaper and there's hundreds of thousands of games laying out there not being used for anything it would be murder NOT to fashion them into other carts people would use.

Tell me when you can get a NES game case, mapper, PCB with 8KB CHR-RAM and 8KB WRAM for less than $3. That will never happen. And nobody will take the leap and produce boards with MMC3-quality mappers for use for cheap, so the only way to get a really good mapper is to use donors.

3gengames wrote:And nobody will take the leap and produce boards with MMC3-quality mappers for use for cheap, so the only way to get a really good mapper is to use donors.

Not sure what you consider cheap but I'm actually in the process of creating MMC3 capable boards.


While it is significantly cheaper to use donors, it's significantly less time consuming to produce sizable quantities of games using new parts. I could assemble 5-10 boards in the time it would take to hack up rewire and troubleshoot ONE donor. So really your argument is only valid for small production quantities or making a game for yourself alone. If you consider the cost of time they become cost competitive quickly. The only way they'd be significant cheaper is if you or someone else was willing to offer up the labor to convert donors for free.

That and you'll never convince the large population of the community that doesn't support hacking donors in large quantities. I'm pretty sure many more action53 carts will sell if they use all new parts compared to if they used donors even if they cost $10 more. You can complain that the market needs to "get over the fact of using donors" but that's alone isn't going to change anything. So until then your argument is moot when considering production quantities larger than a dozen or so...

infiniteneslives wrote:If you consider the cost of time they become cost competitive quickly.

So that I can quantify the cost of time, how long does it take to rewire one SGROM or SNROM game for PRG flash, including running three CHR address lines out to the PRG, and test it?

But there are other advantages of using all new PCBs. First, I imagine a ROM completely soldered to the mainboard would be more structurally sound than one that has had a whole bunch of pins lifted. Second, one can put in a CIClone, which lets one cart service NTSC NES, PAL A, and PAL B.

A mapper based on #34 with D7-D6 repurposed for MMC1-style mirroring control (1/V/H) would take about three chips: a 74HC377 (8-bit flip-flop), a 74HC153 (4 to 1 multiplexer), and a 74HC20 or 74HC04 to invert R/W into /OE to avoid bus conflicts. Someone on IRC recently gave me a rule of thumb that once a mapper has four discrete chips in it, that's when one should start using a CPLD.

tepples wrote:and a 74HC20 or 74HC04 to invert R/W into /OE to avoid bus conflicts

Why bother with preventing bus conflicts instead of working around them? While I agree that it's nicer to be rid of them, either the pirate solution (use address lines instead of the data lines) or the traditional homebrew solution (tables) seem eminently acceptable.

That said, it seems to be almost trivial cost: Digikey sells 1-gate variants of the 74'00, 74'02, 74'08, 74'14, and 74'32 for 63¢-70¢/10 (and $36-$38/1000).

lidnariq wrote:Why bother with preventing bus conflicts instead of working around them?

The menu already works around bus conflicts. When switching from the last bank (which contains the menu) to another bank, it reads the bank number from the game list and writes it back to the same location. But when switching from another bank (such as one holding a compressed screenshot) back to the last bank, it has to linearly search for a $FF byte starting at the reset vector. (Both reset patches include a $FF byte.) Eventually I plan to add support for individual games that surpass 32K, and I'll have to specify an ABI for how to make a table that the ROM builder can patch properly. A game using multiple mirroring settings, for example, would need a copy of the table for each mirroring setting.

Digikey sells 1-gate variants of the 74'00, 74'02, 74'08, 74'14, and 74'32 for 63¢-70¢/10 (and $36-$38/1000).

And how much more does the assembly cost?