nesdev.org

FARID wrote:I want to make a 4 in 1 cartridge including three TLROM games and SMB3. How can I disable using SRAM (WRAM) in SMB3?

You won't be able to just disable it, SMB3 needs it.

(perhaps you meant enable it?)

Either way your only real option is to get a TSROM board so you have the WRAM for SMB3. You could add WRAM to TLROM like I said earlier but it would most likely be a mess. Basically converting TLROM to TSROM.

And like tepples is saying, chances are the games that don't use the WRAM (games that originally used TLROM) won't care that there's actually WRAM there and they'll ignore it. So with that assumption all you'll need to do is use your reset bankswitch circuit for all the rom images.

FARID wrote:How can I disable using SRAM (WRAM) in SMB3?

You can't "disable" it. The whole game was programmed to used that extra memory, which makes it essential for the game to work. Since the game was programmed to work with 10KB of RAM, you can't expect the same program to work with just 2KB.

The game could probably be reprogrammed from scratch to use only 2KB of RAM, but that would require an insane amount of work without any real reward, so I doubt anyone would want to do it.

It would be much, much, much simpler to just add the SRAM to the cart. The wiki has some information about how to do it.

I guess it would be useful to post this here as well, it's about Mario Adventure on PowerPak: http://www.nintendoage.com/forum/messag ... =21#bottom

myself at NA wrote: I tried it now, doesn't work.

Then I looked at it for 10 minutes in Nintendulator and figured out it simply needs to have the WRAM page 7000-7FFF cleared to work. Simply loading an empty .SAV file before starting the game does the trick.

This would also explain why some people have had it working with some RAM chips and not others (different initialization values).

If somebody wants to hack the ROM to fix this issue, remember that the game probably uses some of the RAM at 7000-7FFF for the save stuff, so you should only clear the parts that aren't used for that *OR* add some kind of signature check in the code (if there isn't one already).

EDIT: Oh yeah, you also need to pad the CHR size to 256KB. PowerPak does not support non-power-of-two bank sizes.

Really? That was the big issue? What about MMC3 scanline IRQs? Didn't the game have a problem with those?

It's not the MMC3 IRQs that stop the game from booting. They just screw with the status bar later on.

We probably need to make a "Fake MMC3" mapper, which uses a scanline counter based on a timer (like VRC6) instead of watching A12. Then the game would run flawlessly.

Dwedit wrote:We probably need to make a "Fake MMC3" mapper, which uses a scanline counter based on a timer (like VRC6) instead of watching A12. Then the game would run flawlessly.

That or a fake-MMC3 mapper that spreads the A12 rises by 60 or so dots instead of the roughly 12 dots of authentic MMC3. That will count as expected unless all eight sprites on a given line are from $0000-$0FFF.

Can somebody please put together a combined IPS patch that applies both the Mario Adventure hack and also pads the CHR size to 256KB?

Mario Adventure was also designed for FX3's old palette, which no longer resembles what newer emulators use. For example, the dark blue is far too bright, and the dark yellow colors are instead a rich orange-brown, the red is super-bright, and in general, the colors are much lighter than the new darker palettes.

Maybe the game needs a palette hack to update it to the newer color sets.

Dwedit wrote:It's not the MMC3 IRQs that stop the game from booting. They just screw with the status bar later on.

What level uses tiles from both pattern tables?

How about level 1-1? Climb the beanstalk, and pick up the clear block before throwing it at the brick.

Dwedit wrote:How about level 1-1? Climb the beanstalk, and pick up the clear block before throwing it at the brick.

OK thanks. Yep, the IRQ problem is definitely there (fortunately it doesn't make the game completely unplayable, at least in that specific case). BTW I didn't mean to imply there was no problem with the IRQ, just wasn't sure if it was supposed to occur right away or later on in the game.

So, if somebody feels up to the task, change the mapper to VRC6 (shouldn't be too hard if the IRQ is only used for the status bar), pad the CHR to 256 KB and fix the WRAM initialization code. To clarify on my earlier quote, the game never clears 7000-7FFF, yet expects *some* of the values in there to be 0. It's not OK to clear all of it unless you want to lose the ability to save altogether.

Two years later and this thread is still alive...amazing in any board really, but I have some good news for everyone.

Last night I was experimenting with my copynes and a newly aquired burner (Genius G540) when I noticed somthing odd about a previously problematic game. Mario in Some Usual day started working on my TSROM board suddenly...So I figured that since it was behaving interestingly I'd give the other known problematic SMB3 Hack, Mario Adventure, a run for it's money. To my surprise it worked...suddenly, it dawned on me...I was using other games that were writing to the WRAM in the cart, that may have initialized them just right so that these 'problematic' titles could operate. So I experimented a little bit...I loaded the WRAM with a fill of FF, and Mario Adventure started doing it's usuall music rant with a black screen...then I filled the same WRAM with 00, and lo and behold, it started playing.

Checking the WRAM init code, it appears that only 6FFF-6000 are erased to 00 (I believe this point was already made in this topic), however, the upper half of the WRAM is untouched (except 7D00-7DFF when erasing a save via UP + Select at 'PRESS START').

I've completed a patch that redirects the WRAM initialization code to a code cave with more space so that I can initialize 7FFF-7E00, then 7CFF-6000, fixing the issue.

Additionally, I've added a check to WRAM byte 7DD6. It appears to be unused, but zeroed when erasing the save. This is a failsafe in case the save somehow becomes corrupted, but is not foolproof. It will erase the save if the value at 7DD6 is not 0.

The suspect bytes 7A55 freezes the game with any value other than 0 (mabye pause flag?) and 7AF7 controls some loop in the music code (needs to be 0 on init to work properly).

Here's a zip file with two versions of the ips file (one for a PRG-ROM binary, and one for a .NES file. It doesn't matter if your nes file has the CHR expanded of course).
http://www.mediafire.com/file/kcqc5zgrq ... e-AWal.zip

Yeah thanks you !
Good work !
Will try that tonight !!

Good job dude, haha. So have you analyzed it and made a map of what the WRAM locations mean? Like, what's needed to save information? I'm sure if somebody would have known it'd of been fixed a while ago, I think people don't like hacking hacks, [Myself] especially that don't work for real because it's probably bad code, like this.

But still, great job dude. You're probably going to be worshiped as a saint now by most people, heh.

Very cool indeed but just wanted to point out that thefox managed to find the issue and make it work with the powerpak a few day before but now the problem is compeltly solved thansk to AWal. People waited for years to have it figured out and now we have 2 separate peoples fixing the game in the same 2 weeks? Good job guys, I'll be sure to test AWal patch on my powerpak as soon as I can get a stupid CF card and CF card reader,(pretty hard in this SD card era we're living in:P) so I can finally see what all this fuss about