[libretro] SRAM incompatibility on Little Endian platforms

[ekeeke]

[libretro] SRAM incompatibility on Little Endian platforms

[inactive123]

The libretro.c implementation does not use those functions indeed - this is done by design.

Savestate loading and saving is serialized so that it can be used for rewind purposes as well (and netplay). As for SRAM saving/loading - the libretro.c implementation has its own implementation of that.

There have indeed been reports that saves created with Genesis Plus GX libretro are not compatible with, say, Kega or Exodus. If this is due to the aforementioned endian issues I guess we know where to proceed from here.

[ekeeke]

more exactly, Wii, PS3 & X360 libretro .srm files are compatible, but Windows, Linux, Xbox, IOS & Android ones are not for aforementioned reasons

EEPROM saves (used in Rockman Mega World, Wonderboy 5, NBA Jam, etc) are not impacted because they are handled as bytes

And yes, I eventually figured that SRAM was handled directly by retroarch through retro_get_memory_xxx functions although i cannot figure what the "SYSTEM_DIRECTORY environment callback" in libretro.h is if I want to handle more complex RAM (and maybe also Mega CD backup & cartridge RAM) though this ?

So I guess it means the only alternative is to modify Genesis Plus GX core to force SRAM data to be internally handled in big-endian format on little-endian architecture (native format was obviously used for optimization when memory can be accessed directly through pointers instead of specific function calls but it shouldn't be very significant for the few SRAM access games are usually doing)

[inactive123]

The SYSTEM_DIRECTORY callback is there so that the libretro port can query the frontend (ie. RetroArch) about the 'path' of the system directory (since this can differ per platform port). This way we don't have to messily hardcode in some 'filesystem path' to a 'system directory' or make assumptions about where it might be stored in a libretro port.

The System directory is typically the directory where all the BIOS files go that a libretro core might use. For instance, with PCSX ReARMed, it looks for PSX BIOS files in the system directory - same for Genesis Plus GX where it looks for the Mega CD/Sega CD BIOS files inside this directory.

[ekeeke]

Fixed.
SRAM is now by default saved in BIG ENDIAN format, even on LITTLE ENDIAN platform.

This also means that .srm files made before with the libretro port on LITTLE ENDIAN platforms (PC, Android, IOS, XBOX) are not compatible anymore and must be manually byteswapped.

[Oggom]

I'm not sure if this is the right place to mention this, but I've just tested the current libretro core of Genesis Plus GX (20130629) and some sram files still seem to be incompatible with other emulators (Sonic 3 & Knuckles and Phantasy Star IV for example).
I did not use any save files from previous versions of Genesis Plus GX, so they all should be in big endian now.
I've also noticed Sonic the Hedgehog 3 no longer saves correctly. It creates a srm file, but every time I reset the game the save slots are empty.

[ekeeke]

Indeed, I forgot to handle SRAM for some specific mapper used in a few games (namely Sonic the Hedgehog 3, Beyond Oasis / Legend of Thor & Phantasy Star IV)

SRAM will indeed be broken in those games and it might affect gameplay as well, this should be fixed soon

[ekeeke]

Hum, that's weird, for me Fusion .ssm & sgm files are perfectly compatible once renamed to .srm... and the opposite is also true. Can you upload sram files somewhere and tell from which emulator they come from ?

What I am 100% sure is that there isn't any endianness compatibility issues for 8-bit systems, it's strictly a 16-bit problem

[Oggom]

I forgot Fusion uses different file extensions for each system. No wonder it didn't want to load any of the MS/GG saves.
Thank you very much for looking into this!

[ekeeke]

Should now be properly fixed for games using SRAM bankswitching like Sonic 3, etc