Super Mario Bros on MMC3

Super Mario Bros 2 and 3 and the Japanese Super Mario Bros 2 FD conversion all run on the MMC3

I know with a simple counter 74 chip and a large EPROM it is possible to cycle running these games on a MMC3 board just by pressing the reset button.

For an video games exhibition I want to have all the Super Mario Games running on a NES, however the original SMB doesn't use a mapper and I was wondering if there would be any way to get SMB to work on a MMC3 mapper.

There may be other ways to do what I need but I would prefer a simple reset to select the next game.

SMB1 can run on the same sort of MMC3 board as the MMC3 version of SMB2 (J) if you hack it to set all the banks first.

I forget: does the MMC3 version of SMB2 (J) use CHR ROM or CHR RAM?

I suppose you could have an version of SMB that has its program duplicated in every bank that could be accessed so that it could run regardless of the state of the mapper, precluding the need for a init code. Or write an mapper init routine into one of the unused banks to run right before SMB starts running. I'm sure there are many other possibilities i'm not thinking of.

I don't think it's really something I could test out right now, I think it would require programming some new mapper into a emulator involving your 74 chip and big ROM, added to the TSROM or whatever board.


Tepples: SMB2(J) doesn't appear to be on bootgod's site. Is it an bootleg?

The MMC3 version of SMB2 (J) is a mapper hack (by the homebrew community) of a bootleg (by Chinese pirates).

MMC3 fixes only $E000-$FFFF, and I think SMB1's reset vector is in $8000-$9FFF. Any bank, including the last fixed bank, could in theory be switched into $8000-$9FFF at power on. At least some of the mapper init would have to be in $E000-$FFFF, but armed with doppelganger's SMBDis, it should be straightforward to patch in any mapper init you need.

There is a version of SMB1 in the NWC/SMB/Tetris multicart that runs on an MMC3, and a little bit of effort with a debugger will let you extract the right slices.

Glad I was not asking an insane question then.

I will point the information you guys have given me to the person who will be making me the multicart, as I also need him to put back in the (C) Nintendo message in the SMB2(J) hack, so that Nintendo will be happy.

Thanks again.

Someone have found a way to make Super mario Bros works on MMC3 ?

Running SMB in MMC3 is easy. All you need to do is move the reset routine to $E000-$FFFF, add some code to switch in the proper banks, pad the binary to fit the ROM if you plan on burning it to an E/EPROM (best thing to do is duplicate the banks), and reassemble.

But where in $E000-$FFFF would the reset stub fit? Wouldn't the music engine need moved?

SMB is packed pretty full of code and data. However if you had a menu that runs to select your game, you could have the menu do your register setup for SMB.

I assume you're referring to the stub needed for the MMC3.

It is true that SMB is tight on code and data. But it's also true that portions of the code are redundant or unreachable, that is, either they never execute, or they execute but accomplish nothing.

Two examples: the routine ResidualMiscObjectCode at $e392-$e39b is never executed. The JSR instructions at $90bf-$90c4 jump to two separate points in the routine DoNothing at $92aa-$92af, which writes to a variable that is never used.

Those two examples alone, plus the 13 unused $ff bytes, give 35 bytes, which should be enough to write a short MMC3 bank init routine.

Then write it and you'll know. You need to setup the 6 CHR registers and two PRG registers. Mirroring register too.

Let's play 6502 golf.

There are also 16 bytes to be had by overlapping BrickShatterEnvData with BowserFlameEnvData.

Ohhh, Mario MMC3 conversions. my faaaaavorite subject! Haha!

If there's one ting left I wish I had, it'd be a menu.

Super Mario Bros code is full of rough and sandtraps, but you managed to pitch it onto the green with plenty of strokes under par. Good job.

In an SMB hack I worked on, we expanded the ROM by moving the music data and code to a dedicated bank. This freed up a huge amount of space for lots of hacks.

The reset vector was changed to point to the mapper initialization routine, which jumped to the original init routine once it was setup. The music routine was replaced with a stub that swapped the music bank in, ran the original, and switched back. It all seemed to work pretty well.

The code was based on a version of Doppleganger's disassembly that was modified to build with the cc65 toolchain. This made making changes much easier than hex editing or whatever.

Of course one problem with basing a hack on SMBDis is figuring out a way to distribute your hack as a patch. Any reassembly that moves things around will cause the IPS file to contain nearly the entire ROM.

That was a problem with my Splatterhouse Famicom patch to MMC3. Alot of data had to be shifted around or duplicated. I ended up writing an entire program in C to patch the original ROM. Sometimes IPS just isn't going to do what you want. Well i guess it will but you'll have a patch that as you said basically contains a significant portion of copyrighted data.

Our solution to the patching problem was crossing our fingers and hoping to not get sued. Not the best strategy, but so far, so good.

Considering that source code was also made available, we couldn't exactly keep our hands clean anyway.

I get the feeling that the use of IPS patches has become more due to tradition or convenience of file size than any tangible legal loophole, similar to how ROM sites 15 years ago used to all have a disclaimer that read "For education purposes only! You must delete any ROMs you download within 24 hours or they will become ILLEGAL!". Can anyone even pinpoint the threshold where an IPS patch suddenly becomes "illegal?"

There is a simple and obvious point: When you apply an IPS patch to a bunch of zeroes, and get a working file.

There are only nine people in the United States who can pinpoint when "the amount and substantiality of the portion used in relation to the copyrighted work as a whole" becomes excessive.

Too true Tepples, but keep in mind that in the US, anyone can make and impose that decision upon you with a law suit. Even if the claim doesn't hold in court, the act of being filed is often detrimental enough to cause a chilling effect.

It wouldn't be too terribly difficult to construct a diff and patch utility that would describe an output file as a series of offset and length pairs of an existing reference file, and only include raw data when a sequence of two or more bytes does not appear in the reference file. That way the patch is guaranteed not to contain any data from the original.

I have only one method of determining if something what I host on my own site is illegal or not: If court orders me to take it down, then it is illegal. If some private company (say, Pretenda Law) tells me to do it, I say to them show me court order. If they fail to do so, I conclude what I'm doing is in legal boundaries. And for DMCA notices? My site isn't hosted in U.S., so if I get one, I tell them to give me any reason to listen to U.S. law when I and my site lives in europe.

So what happens when they do an RIAA/BPI and say "take it down and pay us $3,000 or we will sue you for $150,000"

TL;DR - Laws suck, unless I'm the one who's had my rights violated

I say do as you wish, then do Kim Dotcom on them. Possibly with EFF and Dotcom's help.