search

agg23 / openfpga-NES

NES for the Analogue Pocket
GNU General Public License v3.0
187 stars 7 forks source link

SMB3 Romhacks not working #5

Closed Nam-Ereh-Won closed 1 year ago

Nam-Ereh-Won commented 1 year ago

Version (or build number)

0.1.1

Steps to reproduce

First I verified I had the correct ROM version(s) and matched the hash to the listings on the following romhacks: Super Mario Ultimate Mario Adventure

I was able to successfully patch the ROMs and test in an emulator on my PC prior to loading them onto my Pocket.

Expected Behavior

Games to launch and play successfully.

Actual Behavior

In Mario Adventure, the music plays, but input is unresponsive and the screen is black. In Super Mario Ultimate, it's stuck in a boot loop. After displaying the "THIS HACK IS NOT TO BE SOLD!" screen, the graphics get scrambled and it resets.

Additional Context

I also verified that the base ROMs used will run just fine with the core and I've successfully ran some Zelda II romhacks on my pocket such as Zelda II Redux.

Nam-Ereh-Won commented 1 year ago

Both of these romhacks add saving, so it may be the same issue as #13 and #16

Nam-Ereh-Won commented 1 year ago

The same issue is present on the other NES core on the Pocket. GreatHierophant provided a workaround in the comments.

I took a look at the save files that were generated when starting the games. The one for Mario Adventure was zero'd out until byte 0x1000 and FF'd the rest of the way. The one for Super Mario Ultimate was all FF'd. Zeroing out the save file for both resulted in functioning games!

tarikalmashni commented 1 year ago

I commented with a suggestion on the linked workaround issue to add a core option to overwrite the save file with 00s on the device (from within the core menu) so at least no PC is needed to get such rom hacks running on the go.

agg23 commented 1 year ago

The problem is ultimately that the hack is relying on a known initial state for battery backed RAM, which it should not be doing. I can remove the setting that's initializing RAM with 0xFF, but it may cause other problems (and won't necessarily fix this one), because then RAM will be initialized to a semirandom state based on what was previously in the RAM (you could probably transfer saves between ROMs this way, though there will be some data loss). I can also add a chip32 program that initializes RAM with 0x0, but that's still technically wrong, as your battery backed RAM will have random values

agg23 commented 1 year ago

Fixed in 0.3.1