mgba
mgba copied to clipboard
mgba-emu
Retroarch mgba save problems
I have a save for the zelda a link to the past/four swords and the save acts like it is blank on retroarch with mgba core but if i use the standalone mgba emulator it reads the save fine.so i dont get why this is happing and its very weird.The save is named correctly after the rom and the correct size.i matched a test save to the one i have and it seems to match.I hope this can be fixed.
Please upload the save file, and also which version of the core are you using?
I am using c7dba6b version of the core witch should be the latest one.So here are 2 saves the original 64kb one and the 8kb one that i reduced in size from the original one that worked on the stand alone mgba emulator as a .sav so i dont know if the size difference matters to retroarch but neither work.here is the link https://www.dropbox.com/s/n1p1q6fmwoommzd/zelda%20savess.zip?dl=0
Um really need help here with this issue.i already uploaded the save files and its almost been a week....
Sorry about that. I thin the issue is that the RA frontend decides the save should always be a big size despite the fact that mGBA standalone sees this and decides it's the wrong save type as a result. I haven't really looked at it though.
I also have this issue. I wonder if there is a theory as to why it could be happening and indeed any possible workarounds? mGBA seems to save both .srm and .sav files. To my understanding from posts online, RetroArch only takes .srm.
mGBA standalone only saves .sav files. The format is the same, it's the extension that's different.
In this case, there seems to be an issue in the way mGBA is saving games, so simply renaming the extension is not sufficient.
This seems to be happening because the .sav files mGBA creates are of an "unknown" type. I don't know why this is, but both the old gbaconv C program, and mGBA's own save conversion tool, cannot recognize the type of the .sav files mGBA creates. In the mGBA save conversion tool, mGBA will show "No valid formats found" for affected saves.
Despite this, these strange .sav files will load and save just fine in a standalone desktop instance of mGBA. But since Retroarch is more strict, these saves will not load into Retroarch until they are converted, such that they are detected as a particular save type (i.e. FLASH 512kbit). If you try, the mGBA core in Retroarch will just act as if there was no save file at all.
Since mGBA can't recognize its own save format, I was not able to use mGBA's built in converter, but I still needed a way to convert a save file so that it would load in Retroarch. To do this, I exported a GameShark save from mGBA, then used this online save converter to convert that back to a .sav file. The resulting file is a "proper" .sav file that had a correctly detected save type in both mGBA's save converter, and the gbaconv C program. I was then able to use gbaconv to convert this to a .srm save, which loaded in Retroarch just fine.
I'm not an expert on GBA saves, but there seems to be some save type property that mGBA is not saving for some reason.
TL;DR - To reproduce the issue, start a game in mGBA, save it, then open mGBA's save converter tool and try to load an that same save file as the input file. If the save is affected by this issue, mGBA will show "No valid formats detected," and thus this save will not load properly in Retroarch or most other emulators. I don't know if all games are affected, or what causes this.
Can you please upload some of these "unknown" files and tell me what game they're associated with? If you're talking about the Pokémon games with RTCs, that's due to the RTC data being appended at the end. The save converter in mGBA dev builds can strip that data. That said, that RTC data footer postdates this report by well over a year.
Sure, here is a new one I just created:
Rockman EXE 4.5 - Real Operation (Japan).sav.zip
You are right, this is an RTC game. This was created using mGBA on Windows, the stable 0.10.2 build (mGBA-0.10.2-win64).
I'm not sure if converting it in the weird way I did destroyed any RTC data, but the game didn't seem to care, and the clock was still correct.