Add backup memory import/export functions to interface API

[Konstantysz]

Problem

The interface API has desmume_savestate_load/save for savestates but nothing equivalent for battery saves (.sav/.dsv files). This means tools using the library can't load in-game saves programmatically - they have to use the GUI first.

Solution

Added three functions to interface.h/cpp that wrap the existing BackupDevice methods:

/**
 * Import battery save file with optional size override.
 * Supports .sav (raw), .dsv (DeSmuME), .duc (Action Replay), .dss (DSOrganize).
 * The emulator will automatically reset after successful import.
 * 
 * @param filename Path to battery save file
 * @param force_size Backup size in bytes (0 = auto-detect, or explicit size like 524288 for 512KB)
 * @return TRUE on success, FALSE on failure
 */
EXPORTED BOOL desmume_backup_import_file(const char *filename, unsigned int force_size);

/**
 * Export current battery save to .dsv file.
 * 
 * @param filename Destination path for .dsv file
 * @return TRUE on success, FALSE on failure
 */
EXPORTED BOOL desmume_backup_export_file(const char *filename);

The implementation is straightforward - it calls BackupDevice::importData() (which already handles .sav, .dsv, .duc formats) and resets the emulator on success, same as the GUI does.

Testing

Compiles cleanly on Windows (VS2022 x64)
Will do functional testing through py-desmume bindings once this merges

---

The functions follow the same pattern as the existing savestate API, just for backup memory instead. Let me know if you want any changes to the implementation.

[rofl0r]

what's the difference between raw and file api(s) ? could need an explanation in the header.

[Konstantysz]

what's the difference between raw and file api(s) ? could need an explanation in the header.

Great question! I'm actually reconsidering whether desmume_backup_import_raw() is necessary. The force_size parameter is an edge case feature, if the auto-detection in BackupDevice::importData() would fail. Would you prefer I remove desmume_backup_import_raw() and keep only:

• desmume_backup_import_file()
• desmume_backup_export_file()

This would make the API simpler and, if the force_size parameter would be needed by someone in the future, it might be added.

What do you think?

[rofl0r]

This would make the API simpler and, if the force_size parameter would be needed by someone in the future, it might be added.

changing a C api after the fact isn't a great idea. since the upstream api already uses the force_size parameter, i'd just add it to the interface api as well and document what it's for in the header.

[Konstantysz]

This would make the API simpler and, if the force_size parameter would be needed by someone in the future, it might be added.

changing a C api after the fact isn't a great idea. since the upstream api already uses the force_size parameter, i'd just add it to the interface api as well and document what it's for in the header.

I've added documentation. I hope it is in this repository coding style.

[rofl0r]

well done now you only need to rename _raw to _file and remove the less powerful existing _file api.

[Konstantysz]

well done now you only need to rename _raw to _file and remove the less powerful existing _file api.

Done! Simplified to single import_file() function with force_size parameter.

[Konstantysz]

@rofl0r I see that I need to provide a fix to this code. I got to access somehow MMU_new.backupDevice.exportData() and MMU_new.backupDevice.importData().

[rofl0r]

@rofl0r I see that I need to provide a fix to this code. I got to access somehow MMU_new.backupDevice.exportData() and MMU_new.backupDevice.importData().

hmmpf. code looked good and i manually triggered workflow runs, but for some reason only the appveyor action ran. yes, please provide a fix asap.

[rofl0r]

i've reverted this PR for now. feel free to file a new one - based on master - once you got it working and passing our CI, as well as actually tested it - because what you did here didn't even compile.