MegaDrive: SRAM is disabled when using SSFII mapper

[Awuwunya]

So, I've been working on a project lately, and this project requires both the SSFII mapper and SRAM. However, even though SRAM is created, you can not enable it. Any attempts to enable SRAM will still resulting in reading from ROM, an no writes will occur. I have tested the exact ROM in Fusion, Regen, and the latest RetroArch release of Genesis Plus GX as well as compiled binaries from the source itself, and on all of these it works correctly. I am not able to test on Mega-Everdrive, but from my past tests it should work. To me it seems to be an issue with Bizhawk. I have created a test ROM, to verify my findings are correct. Indeed, Regen and Fusion complete it, Bizhawk fails at SRAM portion, and oddly my build of Genesis Plus GX does nothing.

[vadosnaprimer]

Does it still work with anything other than SSFII?

[Awuwunya]

Sorry, but I am not sure I understand the question. If you mean that if SRAM works without the SSFII mapper, it does work at 2MB with the title saying "SUPER STREET FIGHTER2 The New Challengers ", but no more than 2MB. However, it does work fully even up to 6MB if I alter the title. However, if I do alter the title then the SSFII mapper does not work (even if I add "SSF" after SEGA in the console field).

[vadosnaprimer]

I mean games that don't use that mapper.

[Awuwunya]

yes. It works on all games I've tried as well as other homebrews/ROM hacks.

[alyosha-tas]

I looked into this issue. The issue is in md_cart.c. The mapper is not emulated correctly in this version of gensplus gx, the register to turn on SRAM is not emulated. For ROMs less then 2MB, SRAM is turned on automatically since there's no ROM in the way.
It looks like properly emulating this would require another state variable for the ROM banks that are masked out while SRAM is turned on.

Looking on Github, it looks like the current version of gensplusGX also does not emulate this correctly , it just gets lucky to have SRAM turned on by default (for some reason erasing the check that kept it from turning on in the previous versions) but still does not emulate the SRAM enable register.

Here's documentation on this mapper:
https://emu-docs.org/Genesis/ssf2.txt

I'm not sure how thoroughly this test ROM attempts to test this mapper or what exactly it's doing.

[ekeeke]

There is actually no proof that this 'SRAM enable register' actually exists in SSF2 mapper. Someone would need to patch the real cartridge using a Game Genie or Action Replay so it writes $01 to $A130F1 instead of $00 on startup and see if this actually disables the ROM (and crash the game). However, I seriously doubt it considering there is no SRAM chip inside SSFII cartridge and this is the ONLY game that uses this specific mapper chip.

The thing is that the document linked above is actually based (at least for the A130F1 register part) on the documentation of some 32x development cartridges which describes this SRAM enable functionality but this is NOT the same chip that is used in SSFII cartridge (and emulated by Genesis Plus GX). Again, since there is no SRAM in SSFII cartridge, the assumptions in the document about SRAM enable register bits were definitively not possible to verify on a real SSFII cartridge.

So, basically, this test ROM is using a mapper that does not exist on any real MD cartridge and will likely never work on real hardware either.

[alyosha-tas]

Interesting, thanks for the insight. What else could they be trying to do by writing to that register in the first place then? Seems oddly specific, but I have no access to any hardware so I have no idea.

[ekeeke]

Most likely because it was initially developped on devcarts which had this register.

Btw, I forgot about that but in latest version of Genesis Plus GX (not sure which one Bizhawk is based on but it seems quite outdated), this "official" devcart mapper is enabled by default for any games unless they are known games that use a specific !TIME handler. This means this test ROM would work just fine providing it does not try to identify itself as SSFII in the ROM header.

[Sappharad]

@ekeeke Is this a valid reason to support SRAM in the SSF mapper?
https://forums.sonicretro.org/index.php?threads/sonic-delta-40mb.39203/page-4#post-960741

This guy actually built a cartridge with both and provides the schematic:
https://www.neto-games.com.br/hardware/sonic_delta_40Mb_hardware.php

[ekeeke]

Hi,
It's already supported in official repository: https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/cart_hw/md_cart.c#L1684

This is the default !TIME write handler and it supports both the SRAM enable/disable mapper and SSF2 mapper.

The commit you are missing (among many others, looking at the date in md_cart.c header in Bizhawk repository) is the following one: ekeeke/Genesis-Plus-GX@c6b62fc

To enable SRAM for games larger than 2MB, the hack also needs to have a valid ROM header indicating backup RAM use ("RA...."). See https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/cart_hw/md_cart.c#L878 and https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/cart_hw/sram.c#L85

Lastly, the ROM should also not use Everdrive specific header ("SEGA SSF") otherwise the emulator will emulate Everdrive extended SSF2 mapper, which does not support SRAM enable/disable switch (as it allows bank 0 to be remapped). See https://github.com/ekeeke/Genesis-Plus-GX/blob/master/core/cart_hw/md_cart.c#L551.

Similarly, the ROM should not use same game title as SSF2 retail game in header, otherwise the emulator will emulate SSF2 cartridge mapper, which, as explained in previous posts, do not support SRAM.

[nattthebear]

This bug has been closed for some time. If there's anything actionable here, please create a new bug so I can look at it.

[Sappharad]

@nattthebear I know. I replied here primarily to follow up on the discussion for the intended behavior of GPGX. I'll open another issue if I think changes should be made.

[ekeeke]

If you ask my opinion, this issue should rather be reopened since it was never fixed in the first place (SRAM is still not enabled with SSF2 mapper in Bizhawk GPGX version) and the commit mentioned for fixing was actually incorrectly back-ported (see below).

For the record, I just tried Neto's ROM hack and it indeed fails in official GPGX: the reason for that is that for some reason he puts "SEGA SSF" in ROM header, which, as explained above, is normally reserved for games that use Everdrive extended SSF2 mapper. That extended mapper allows remapping of the first 512K bank (through writes at $A130F1 address), which breaks that specific ROM since it writes to that address to enable/disable SRAM, which ends up remapping the first 512K bank to some unexpected ROM area...and crashes. It also means this ROM probably would not work either on Everdrive flashcarts that support SSF2 extended mapper (like Mega Everdrive X7).

I confirmed that restoring this ROM header field with usual value ("SEGA GENESIS" or "SEGA MEGADRIVE") fixes the game in official GPGX (and SRAM saving is working too).

Now, it works in Bizhawk (without SRAM saving though) because you partially back-ported my commit that added detection of Everdrive extended SSF2 mapper ("SEGA SSF") but hacked it to enable "normal" SSF2 mapper instead (so first 512K bank is not remappable). This is not correct as the spec of Everdrive extended SSF2 mapper (which kinda coined the "SEGA SSF" identification field) explicitly allows remapping of bank #0 (see http://krikzz.com/pub/support/mega-everdrive/x3x5x7/dev/extended_ssf-v2.txt for full details).

The correct solution is to instead backport the following commit:
ekeeke/Genesis-Plus-GX@c6b62fc

and remove incorrect "SEGA SSF" field from that ROM header

[Sappharad]

@ekeeke That stuff was my fault. Esrael had the SSF header in his rom at one point, so I added code to my local copy that basically does what you see in this repo to make it work.

He took the header out, which broke my local copy of BizHawk and I reported it as a bug so he put it back in. Then I provided the fix here which was included in 2.4.1.

I guess I should let Esrael know to take the header out. Sorry.