Re: built this on cart in the past and it worked: Excellent, that's good to know.
I finally figured out the patch idiocy. I had to read the patch README closely. The checksums they give are from FCEUX, which for whatever reason decides to give checksums of only raw PRG/CHR (i.e. without header), which makes the checksums given very confusing.
The IPS file is intended to patch against the actual .NES file, the romhackers just chose to use "FCEUX checksums" in their README. Here are the proper file checksums of everything:
Code:
Source: 811b027eaf99c2def7b933c5208636de *Super Mario Bros. (W) [!].nes
Patched: d0443cd132e2642673599794ebd6ad75 *patched.nes
Anyway...
The difference as you know between SKROM and SLROM is that SKROM contains an 8KByte SRAM chip for PRG-RAM, mapped to the $6000-7FFF region. I have no idea if the romhack would use/need the extra RAM for anything -- if so, it could potentially explain bugs, like if they were storing MMC1 register values in temporary variables located there. Let's try to find out.
The pictures you provide aren't fully indicative of the problem, but I *think* I know what's being depicted -- when you scroll horizontally, the screen has a weird sort of "half-scrolled catch-up" thing going on. Yeah, that's usually wrong mirroring. Let's get into it further. I'm using NestopiaUE 1.49. The game does play fine. Here's the details:
Header before patch (i.e. stock SMB):
Code:
4E 45 53 1A 02 01 01 00 00 00 00 00 00 00 00 00
System: NES-NTSC
Board: NES-NROM-256
PRG-ROM: 32k
CHR-ROM: 8k
Solder Pad: H:1 V:0
Battery: No
Dump: OK
Header after patch:
Code:
4E 45 53 1A 04 01 13 00 00 00 00 00 00 00 00 00
System: NES-NTSC
Board: SxROM (non-standard), Mapper 1
PRG-ROM: 64k
CHR-ROM: 8k
W-RAM: 8k
Solder Pad: H:1 V:0
Battery: Yes
File: patched.sav
You'd think it wants horizontal mirroring, but I'm suspecting not (given that it's a horizontal-scrolling game). Let's check FCEUX:
Code:
PRG ROM: 4 x 16KiB
CHR ROM: 1 x 8KiB
ROM CRC32: 0xb25c00ab
ROM MD5: 0x682b381e2e8ea3a53ea2d201d9fbd15c
Mapper #: 1
Mapper name: MMC1
Mirroring: Vertical
Battery-backed: Yes
Trained: No
Cute -- vertical. This could be from an internal database that's forcing the mirroring though... so which mirroring is true? Let's keep using FCEUX to find out, which lets you force/set mirroring in real-time:
Upon loading the game in FCEUX and getting the title screen, I checked the mirroring under Nametable Viewer. It's set to
Vertical (this option can/will change based on the 6502 code that configures the MMC1). I play a bit -- it's still vertical. If I switch the mirroring to
horizontal in the GUI while at the title screen, and then start the game, I get the exact behaviour (I think) you're describing -- a kind of broken/half-scrolling method that's wonked out.
So in summary:
1. This romhack actually uses vertical mirroring, best I can tell. If triple verification is needed, I can happily go look at the MMC1 writes for mirroring and determine from that. But vertical makes the most sense, IMO.
2. This romhack claims to need PRG-RAM, which means
you need to use an SKROM board. Whether or not the battery is
needed is unknown to me; maybe this romhack retains high scores? I don't know. If a battery is needed, this link can help:
https://wiki.nesdev.com/w/index.php/SxR ... _retention . I checked inside of FCEUX's debugger + memory viewer --
there is a lot of data in the $6000-7FFF range, so this game definitely needs PRG-RAM.
Otherwise,
Wizardry is an example of an SKROM game that has a battery. There's probably others.
HTH.