MiSTer FPGA Forum

Last night, I ran into a weird issue with Megaman X. In the penguin stage, there is the part where you drive the robot then I got to the end and jumped on top of a roof. Then all of a sudden, the screen popped up showing I had the special weapon. Then it showed the password screen and the game started back at the beginning of level 1. The roof I jumped on was at 2:45 of this video https://www.youtube.com/watch?v=U1bpiFF5ZIM

I noticed someone else ran into an issue with the same stage: https://github.com/MiSTer-devel/SNES_MiSTer/issues/228

I'm running the lastest snes core too.

Thanks!

Sounds like the games copy protection: https://tcrf.net/Mega_Man_X#Copy_Protection

Maybe SNES core needs to check the ROM type information in the header and disable SRAM writes if the game doesn’t have it?

MiSTer's core should have the SRAM sorted out as it would likely cause issues with many other games if this was not correct. Killer Instinct is another game with no SRAM that will show an Anti Piracy screen if you have SRAM detected. But Mega Man X (and Demon's Crest I believe) also require proper ROM mirroring.

If either SRAM mapping or ROM mapping doesn't match the real cartridge you can have issues with the protection. As a temporary fix you could use the cracked ROM. If you can't find it, UCON64 with switch -k should apply the crack.

Maybe the ROM or RAM mapping got broken because I don't remember having any issues with Mega Man X (v1.1) tripping the protection.

Other games with SRAM based copy protection include: Donkey Kong Country 1 & 2, I forget if the 3rd one does too, Killer Instinct, Super Mario All-Stars, Earthbound, The Ninja Warriors, Kirby's Dream Course, Yoshi's Safari. This is not a complete list but some other ones you could check if they also trip copy protection. I think Capcom is the only one that did ROM Mirroring related protections. I'm pretty sure Mega Man X and Demon's Crest do that and possibly Super Street Fighter 2.

It's not just that stage. Not sure why this needed to be a forum discussion, but I'm the OP for that Github thread.

I've had forced early stage exits in every stage I've played; some with items, some without. Sometimes I lose items, sometimes I don't. Non-helpful, other than to establish baseline expected FPGA behavior: This doesn't happen on Super NT with the NOINTRO rom.

I'm not sure at what point copy protection should be kicking in, but I've spent fairly substantial time with Super Mario All-Stars, DKC, Ninja Warriors and all games are behaving roughly as expected. Certainly not dropping out of stages or losing items.

Several of the described copy protections seem to be happening in MMX, but not all. Obviously the FPGA's failing the sniff test somehow, but so far it seems isolated to Mega Man X.

(Demon's Crest also does not exhibit any erratic behavior; it seems only MMX at the moment is triggering copy protection behaviors)

It looks like this game has issues even on real hardware: https://www.youtube.com/watch?v=6gWaFwSZ08Q
(there's a comment in there)

Mega Man X has very aggressive copy protection where as Demon's Crest is more subtle about it. In DC you reach I think it's the 3rd boss who simply cannot die and you're stuck. I am not certain if the protection includes ROM mirroring/mapping or if it's entirely SRAM based.

Mega Man X has both in place. Try using the US version 1.1 ROM. If that doesn't work try using UCON64 with option -k. The game requires correct mapping of the ROM (and other memory) across address space and if things don't match the behavior of the original console and original cartridge it will trip the copy protection which has many effects. All your weird problems are related to that, not the MiSTer SNES core's accuracy other than perhaps the mapping of memory. But I don't recall having any issues when I played the game on MiSTer and I believe I played it for a significant amount of time due to the turbo cpu feature eliminating the slowdown in the game.

I attached an IPS file for US Version 1.1 that will disable the protection. It's the same result as using Ucon64 with option -k. Try it and if your problems go away you can be sure it was related to the protection. I did not check if Ucon64 has patches for other regions/revisions but it probably does.

Update: I took a quick look at Mega Man X (US) (v1.1) and there are 3 protection checks that test if the ROM is mirrored at Bank $40. If these tests fail the protection will take action. This is the only bank that is tested to see if ROM is mirrored. There are 4 SRAM checks, all test bank $70 for the presence of writable memory. If they succeed in writing a value and reading it back the protection will take action. I also checked Demon's Crest and it has 2 ROM mirroring checks comparing banks $80 and $40 which should be mirrors of eachother. If it fails the protection takes action. Demon's Crest also has 2 SRAM checks.

Thanks, appreciate you posting this.

I'll try out 1.1 (patch if necessary, would be interested to see if it's clearable without) and see if that takes care of things. Thanks!

For the record, Arma was definitely beatable in Demon's Crest, so that game is (apparently) passing copy protection checks. Like, this was the first game I've played where it's just gone nutty.

Edit: Just played start to finish 100% with 1.1 without patching, so that confirms that for some reason the NOINTRO (v1) ROM is triggering copy protection, and for some reason whatever it does to check in 1.1 isn't triggered (expected behavior by SNES core!)

rykerrk wrote: ↑Thu Jul 16, 2020 12:30 am I'll try out 1.1 (patch if necessary, would be interested to see if it's clearable without) and see if that takes care of things. Thanks!

For the record, Arma was definitely beatable in Demon's Crest, so that game is (apparently) passing copy protection checks. Like, this was the first game I've played where it's just gone nutty.

Edit: Just played start to finish 100% with 1.1 without patching, so that confirms that for some reason the NOINTRO (v1) ROM is triggering copy protection, and for some reason whatever it does to check in 1.1 isn't triggered (expected behavior by SNES core!)

Make sure your No-Intro Rev. 1 ROM has the following MD5: DF1CC0C8C8C4B61E3B834CC03366611C

This is the MD5 of both GoodSNES v1.1 and No-Intro Rev. 1 ROMs.

Actually, assuming I did the MD5 checksum correctly, my supposed nointro ROM is completely off, assuming namechanging doesn't alter the checksum value (it wouldn't take the MD5 checksum command in terminal the way the ROM was originally titled).

File name doesn’t affect md5 results. Your ROM is probably not a No-Intro then.

bootsector wrote: ↑Tue Jul 14, 2020 1:06 am Maybe SNES core needs to check the ROM type information in the header and disable SRAM writes if the game doesn’t have it?

It's apparently not possible to support all ROMs with this approach. Apparently some games lie in their internal headers as a form of copy protection, and if I understand correctly external 512 byte SMC headers apparently don't express enough information to determine the memory map either. Apparently in order to handle Rockman X 1.0, older bsnes detected the ROM via SHA256 and applied a different memory map to simulate the bodge wiring applied to the original cartridges; I can't be bothered to look up what its current descendant does but imagine it's similar...

Patching individual games probably doesn't scale, although the number of games having copy protection might be small enough that it's feasible. Adding the database bsnes used might be a pain and wouldn't apply to hacks, though presumably the hacks could themselves patch out the copy protection. Adding a new type of header might not go over well... I know the Atari 2600 core uses filename postfixes to determine otherwise undetectable mapping without a database, maybe that approach would be workable without much drama? Or maybe not.

Nearly all commercial releases should have valid information in the internal header. Prototypes and hacks are where it becomes less reliable. No (official) game lies in the header for copy protection. Nintendo wanted that information as part of getting the cartridges produced. It needed to be correct presumably to ensure the correct board configuration was produced. The 512 byte SMC and other copier headers don't contain any useful information for emulators. The only ROM format that does would be the Game Doctor SF format which actually has very versatile memory mapping in the header.

Rockman X version 1.0 is known to have issues. But it's a special case. Loading SNES ROMs can be annoying but in most cases it's not too difficult to figure out the correct configuration. One problem with creating special case handling of ROMs is if the game is then modified your special case fix may no longer work on that version.

I don't think there is any need for any major change.