this is a really cool hack that i wont run on the power pak or real hardware, i asked mottzilla and he couldn't figure it out, anybody know what it could be?
http://www.romhacking.net/hacks/53/
oh and i contacted the hacker and he could only remember this:
"I believe I changed the number of PRG and CHR rom banks in the iNes header to extend the game"
Looks like it has a battery backed save option? Most emulators will initialize the save RAM consistently, but hardware might not. Does the hack detect and recover from corrupt save data?
That was one of the things I checked. Corrupting the save data with various bytes will crash the game when you try to load it. But it doesn't stop the game's menu coming up which has the option to erase/initialize save data. He said the game just black screens from the start.
I don't think the ROM expansion is an issue either. The hack behaves fine in Nestopia and other emulators so I'm not sure what might be the cause. It would be nice to find out. I also checked if any program bank registers were uninitialized but it appears they are initialized before non-fixed banks are accessed.
I didn't look into anything else yet.
I'm noticing weird stuff w.r.t. the PPU address during startup. There is a fill loop at $FDE1 writing to $2007, and it is fine for the first few lines but (at least in FCEUX) the PPU address starts going haywire eventually and it's basically making writes to essentially random locations? That's a bit odd. Strangely, I am not picking up any writes to $2000 or $2001 to interfere with it, not really sure how this is occurring.
Edit: Nevermind, this is probably a bug in FCEUX's debugger. Doesn't occur with Old PPU mode selected, and can't duplicate behaviour in Nintendulator.
On the PowerPak I do at least see some coloured lines on the screen for one frame, indicating it manages to write the palette before it hangs on a black screen. (I see identical coloured lines in Nintendulator 5 frames after reset. On frame 6 the title screen should appear, but on the PowerPak it is just black.) I suppose this is also the first frame the MMC3 IRQ is first needed for the scroll split at the bottom of the screen, but I don't think it quite gets that far, since the curtains are never visible.
Oh no...not this one too...I could've sworn I patched this one as well.
It's the exact same issue too...I'm actually suprised nobody has actually brought it to my attention...I guess fixing one kinda paved the road for a workaround on the others anyways.
I'll see if I can whip up a patch for this one too, as my TSROM gone TKROM dev board doesn't like it unless I blank the WRAM to 00 myself (the AAA battery hack is still kicking apparently too...I figured the Cypress SRAM I was using would've drained it out by now...).
I already see the "Erase Save" code only does 0x7FFF-0x7D00. Just need to "study" it for a while and see what exactly of that is used...
Wow, this game was jam packed in the constant banks...
Get The Patches here.This patch oughta do it. All that's required is to erase the save before the first play. I'd love to fix that too, but I don't believe I'll have enough space to patch that as well.
Also, the unoccupied palettes used at a later point in the game are not fixed and will show black when used (I currently have no plans to fix this).
Just to be clear, what was the problem? It was an issue with save data?
Yep. Mario In Some Usual Day, like Mario Adventure, isn't clearing any of it's WRAM. I didn't really find any significant space to put a proper clearing routine back in, but I did have enough bytes to have the reset code write 0x00 to the problem byte (CPU 0x7955 - WRAM 0x1955). If it's anything but 0x00 the game will essentialy freeze (music still appears to play though).
nice, i didnt know you did this, ill try out this patch on real hardware soon. thanks!
AWal wrote:
Wow, this game was jam packed in the constant banks...
Get The Patches here.This patch oughta do it. All that's required is to erase the save before the first play. I'd love to fix that too, but I don't believe I'll have enough space to patch that as well.
Also, the unoccupied palettes used at a later point in the game are not fixed and will show black when used (I currently have no plans to fix this).
How do you clear the save on real hardware?
Tormenter wrote:
How do you clear the save on real hardware?
One way to do it is to open the cartridge up and use a small cable to make a short between Vdd and Vss for a few seconds on the SRAM chip that hold the save data. You will need to know the pinout of that chip though.
Two problems ...
one, that shorts out the battery (no good for the battery) through a diode (no good for the diode).
two, there's no guarantee that the power-up pattern in RAM is all 0s.
But I don't have a better idea.
lidnariq wrote:
Two problems ...
one, that shorts out the battery (no good for the battery) through a diode (no good for the diode).
two, there's no guarantee that the power-up pattern in RAM is all 0s.
But I don't have a better idea.
I don't think I've seen a cart without some kind of current limiting resistor. Batteries could go bad and and become internally shorted and potentially ruin the console if there was no fail-safe.
Internally shorted batteries would be protected from the power supply rails by the diode.
That said, you're right, I forgot there's the current-limiting resistor there.
lidnariq wrote:
Internally shorted batteries would be protected from the power supply rails by the diode.
That said, you're right, I forgot there's the current-limiting resistor there.
True, I never thought of that. That diode does lots of things. Protecting the battery from the console's higher voltage, relieves the battery while the console is powered and protects the console from shorting out.
Thanks.
yxkalle wrote:
Tormenter wrote:
How do you clear the save on real hardware?
One way to do it is to open the cartridge up and use a small cable to make a short between Vdd and Vss for a few seconds on the SRAM chip that hold the save data. You will need to know the pinout of that chip though.
You should never do this. No good program should require the SRAM contents to be initialized or otherwise be unable to handle corruption. If you do (for a hack or something), then you could use some sort of cartridge reader/programmer device to zero every byte of SRAM. Or if that isn't an option you could program an EPROM with a program to write SRAM for you.
AWal wrote:
Wow, this game was jam packed in the constant banks...
Get The Patches here.This patch oughta do it. All that's required is to erase the save before the first play. I'd love to fix that too, but I don't believe I'll have enough space to patch that as well.
Also, the unoccupied palettes used at a later point in the game are not fixed and will show black when used (I currently have no plans to fix this).
Do you have a patch to fix Mario Adventure? Ive tried it several times, and always locks and has some garbage on the screen =(