Mega Man X3 Zero Project 4.1 save issue.

[TailsGuy]

MMX3 Zero Project adds alot of things to the original game to enhance the experience, and one of those things
the creator added was a save feature.

http://www.romhacking.net/hacks/4086/

When you beat the intro stage, you get the chance to save the game, now, when you select a file, there is a random amount of saves that seem to be there, like, on file 2, there's a 100 percent save of sorts, and the game thinks there isn't anything there. I overwrite the save, but when I reset the game, the saves aren't there.

Does anyone have any idea what this could be? I'm sure it's not a corrupted save.

[MottZilla]

The Cx4 cartridge doesn't normally have SRAM on board. The MiSTer SNES core probably doesn't attach SRAM (it has no reason to) and so the game is reading some other memory for "save data" which is why you see that. And that's also why the hack attempting to write it has no effect. The weird save file data suggests the hack doesn't have any data integrity check (ex: basic checksum mechanism) which would allow any old data to be interpreted as a save file.

The hack I'm sure is intended to be played on emulators which have been programmed to support such things that didn't exist originally. It's possible the SD2SNES has been updated to support it but I'm not sure. The MiSTer's SNES core could certainly be updated to allow for it.

[TailsGuy]

Thanks for the update. I hope someone will do it someday.

[sofakng]

I'm curious about this as well. What part(s) aren't implemented for this to work correctly in MiSTer?

It sounds like the original Mega Man X3 Zero Project cartridge used a Cx4 chip but didn't include SRAM (because it didn't support saves).

Is there something in the SNES header that tells MiSTer what chip(s) are present? Can we just add an SRAM flag or is it not that simple?

[ExCyber]

There are such bytes, but I don't see any obvious problem in how they're interpreted by MiSTer. However, each special chip cartridge type also has its own logic in SNES_MiSTer to handle mapping, so there could be an incompatibility specific to the combination of CX4 and SRAM. The CX4 code definitely has logic and connections for SRAM, but I'm not familiar enough with SNES to immediately understand whether they're correct. Then again, "correct" might be somewhat arbitrary here, since there isn't an original cartridge to compare against.

[sofakng]

Interesting ... It looks like only Mega Man X2 and Mega Man X3 used the CX4 chip?

Does Mega Man X2 also not originally have an SRAM chip?

[the_muteKi]

None of the old Megaman cartridge games used SRAM or similar onboard saves. They were all passwords only.

[MottZilla]

There are such bytes, but I don't see any obvious problem in how they're interpreted by MiSTer. However, each special chip cartridge type also has its own logic in SNES_MiSTer to handle mapping, so there could be an incompatibility specific to the combination of CX4 and SRAM. The CX4 code definitely has logic and connections for SRAM, but I'm not familiar enough with SNES to immediately understand whether they're correct. Then again, "correct" might be somewhat arbitrary here, since there isn't an original cartridge to compare against.

I think you're correct. When the ROM loader detects the Cx4 cartridge type it might ignore any header information that suggests mapping SRAM. Someone that develops for the MiSTer in theory should be able to patch something in there relatively easily. Maybe one of them will see this and decide it's worth their time doing it.

[ExCyber]

I don't really understand the details of the mapping, but it looks like the basic problem is that SRAM is only activated when CX4 reads or writes the SRAM space, not when the CPU does. However, fixing that in the straightforward way causes some obviously wrong junk to be written to SRAM. In principle I could keep digging with SignalTap, but as a practical matter this probably calls for someone with more SNES expertise than me.

[MottZilla]

Are you talking about the Cx4's internal ram? It's been awhile since I've looked at details about the Cx4 but the ROM hack in question is in theory looking to access battery backed SRAM at the "usual" LoROM mapping location for such memory. The Cx4 doesn't need to be and probably shouldn't be involved. If you can find the bits that map your normal LoROM cartridge SRAM and add that to Cx4's setup/init the hack might be happy with that.

But I have no idea how the MiSTer SNES core is constructed, I'm going off my expreience with emulation.

[ExCyber]

Are you talking about the Cx4's internal ram?

It occurred to me that the SNES_MiSTer BSRAM block might have been co-opted as CX4 "internal" RAM, but I don't think that's the case. I didn't really account for the "Program RAM" described in CX4 documentation, but that's apparently too big to fit in the SNES_MiSTer BSRAM block anyway. The "Data RAM" is declared as its own block in the CX4 module.

The Cx4 doesn't need to be and probably shouldn't be involved.

I obviously don't expect the hack to use a CX4 program to deal with SRAM, but the CX4 does need to be involved. Like Super FX and SA-1, CX4 controls the cartridge memory chips because it can perform its own accesses independently of the CPU. Emulators can get away with ignoring this because memory access doesn't inherently cause (emulated) time to pass; any number of devices can read or write memory instantaneously and simultaneously.

If you can find the bits that map your normal LoROM cartridge SRAM and add that to Cx4's setup/init the hack might be happy with that.

In SNES_MiSTer, the standard mapper is a separate module from the CX4 mapper, and the init just selects which mapper is activated. It's not possible to mix and match mappings of individual memories between the two.

[ExCyber]

If you can find the bits that map your normal LoROM cartridge SRAM and add that to Cx4's setup/init the hack might be happy with that.

As I indicated in my previous post, this approach doesn't work as stated. However, one thing that did get saves working was to simply edit the HDL to replace the CX4's BSRAM connections with the ones from the standard mapper, which works because the mappers are never really disabled, just muxed. That made it pretty clear which signals I needed to look at to get SRAM access to work on the CX4 mapper.

I'm slightly paranoid about this tripping some obnoxious copy protection, because I wouldn't put it past mid-90s Capcom to publish a game with an on-cart coprocessor and copier checks.

[MottZilla]

Well I'm glad you're making progress in getting something working. When I said I assume the Cx4 doesn't need to be involved I wasn't aware how much of memory mapping the Cx4 is in charge of. I was thinking if the SRAM area used by the hack is not causing the Cx4 to control the bus then it'd be simple to map SRAM there. But if it does then you'd have to go through the Cx4 to map SRAM.

I'm not sure if any SNES games with coprocessor/enhancement chips also featured any sort of basic copy protections. As for this case, only 2 games ever were made with Cx4 so it's not like we wouldn't find out very quickly if something was wrong.

[ExCyber]

Well I'm glad you're making progress in getting something working. When I said I assume the Cx4 doesn't need to be involved I wasn't aware how much of memory mapping the Cx4 is in charge of. I was thinking if the SRAM area used by the hack is not causing the Cx4 to control the bus then it'd be simple to map SRAM there. But if it does then you'd have to go through the Cx4 to map SRAM.

You had the right abstract idea, I think it's just that you were thinking of a mapping function being "in front of" Cx4 when the mapping function is actually integrated into Cx4. It wasn't immediately obvious to me, either; I just happened to know that it was a possibility based on stuff I'd read about Super FX and SA-1, and got some further understanding from reading the code. If anything, I should thank you for indirectly convincing me to take another look at it instead of assuming it was too complicated.

I'm not sure if any SNES games with coprocessor/enhancement chips also featured any sort of basic copy protections. As for this case, only 2 games ever were made with Cx4 so it's not like we wouldn't find out very quickly if something was wrong.

Yeah, as far as I remember (it's been about 20 years since I've seen it fail, after all...), the main copy protection in Cx4 games is that the Cx4 is gratuitously involved in basic functions like loading sprite data, similar to protection microcontrollers in arcade games. I doubt that the developers really put something more insidious into these games. There wasn't really any point; if a copier went to the trouble of supplying Cx4 functions, correctly masking/mirroring SRAM would have been trivial by comparison. I was mostly thinking of the original Rockman X, where the copy protection was allegedly so touchy that they ended up having to add a bodge resistor to the cartridge to make it reliable, and Demon's Crest, where they made the game run normally for a while and then throw an invincible boss at you.