Mario Adventure ( SMB3 Hack ) on real Hardware !!

marvelus10 · Post by **marvelus10** » Mon Jun 29, 2009 10:24 am

I never tried SMB3 on the eproms but I did try 2 other sets of eproms that were meant for a TSROM board and they both worked fine on both the TSROM test board and the TKROM test board.

flagoss · Post by **flagoss** » Mon Jun 29, 2009 10:26 am

I got the same result on a working TKROM devcart... black screen, no sound and no controller response...

Post by **Memblers** » Mon Jun 29, 2009 2:10 pm

Watch out for different MMC3 revisions (MMC3A, B, etc.). I don't know if they're different or not, but I wouldn't be surprised if they were.

marvelus10 · Post by **marvelus10** » Mon Jun 29, 2009 6:53 pm

Has anyone emailed nesreproductions to see how its done. I'm at a loss here, I don't know what to do next.

peppers · Post by **peppers** » Mon Jun 29, 2009 6:57 pm

Hardware wise its simple, on the software side the hack was developed on emulators and it is broken on actual hardware, I don't know how to correct this personally.

The guy from that site had apparently said he would not release his fix to the public, also he is apparently not selling this title because he has yet to work out all the bugs.

Perhaps some of the more knowledgeable people in the forums would like to offer some insight?

marvelus10 · Post by **marvelus10** » Mon Jul 06, 2009 8:16 pm

Has anyone made some progress, unfortunately I have gotten nowhere with this.

I don't understand how this game differs from the original, it must be more than just a graffix and level hacking for it to change the way the mapper works, and I don't have the time or the patients to learn how to code to figure it out.

Wasgo · Post by **Wasgo** » Wed Jul 08, 2009 2:02 pm

The author of the rom hack has mentioned a few times that the game relies on a bug which only exists in emulators. The game would need to be modified to not rely on that bug.

marvelus10 · Post by **marvelus10** » Thu Jul 09, 2009 8:30 pm

If the PowerPak emulates mappers then why would this not work with a that.

peppers · Post by **peppers** » Thu Jul 09, 2009 9:22 pm

emulateing the hole system and emulateing a device that controlls how the system accesses sertain addresses on its ROM's is differint.

the purpose of a mapper is to allow for bigger ROM's to match up data adresses past the point where the NES'es CPU no longer has addresses. or so I belive but I am ofren wrong if outhers would add more information I would be interested.

Hojo_Norem · Post by **Hojo_Norem** » Fri Jul 10, 2009 2:09 pm

Anybody have any idea what kind of emulator bug is being exploited? Isn't it possible that in the future newer emulators will also have problems running SMA?

never-obsolete · Post by **never-obsolete** » Fri Jul 10, 2009 3:56 pm

It uses sprites from $0000 and $1000, messing up the irq counter.

Wasgo · Post by **Wasgo** » Mon Jul 13, 2009 10:29 am

So, assuming my limited understanding is correct, to get it to run would require moving the sprite references to a different memory address and a new mapper that increases the number of available addresses. Would that be correct?

Dwedit · Post by **Dwedit** » Mon Jul 13, 2009 4:12 pm

In other words, it's using sprites from both the left and right pattern tables, while a game running on an actual NES should only use the right side.

Post by **tepples** » Mon Jul 13, 2009 8:50 pm

Not "an actual NES" but "an actual Nintendo MMC3 chip". An actual NES connected to a Game Pak containing an MMC3-clone CPLD that uses a different algorithm for the scanline counter (perhaps based on PPU A13 not A12) should run the game as intended. But then we first have to figure out how to make an MMC3-clone CPLD in the first place.

tokumaru · Post by **tokumaru** » Wed Jul 15, 2009 11:45 am

tepples wrote:But then we first have to figure out how to make an MMC3-clone CPLD in the first place.

If using sprites freely doesn't break the scanline counter, it's already much better than the MMC3. The only thing missing is 1K CHR bankswitching for both pattern tables.