(0.10.0 Windows 10) 16 extra bytes appended to some .SAV files

[Aerospherology]

I tried looking at a Pokemon Fire Red save file with the save editor PKHeX and the file was not loading in the program, The save file had 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 appended at the very end, making it too large. When that was deleted using a hex editor, it was compatible with PKHeX.

[LunarLambda]

Newer versions of mGBA append the RTC data to the save file. New versions of PKHeX already support this. Update PKHeX.

[endrift]

Fire Red doesn't use the RTC...those shouldn't be appended. Unless it's a ROM hack I guess.

[endrift]

I'm not seeing it on my local copy. Was your version of FireRed a ROM hack?

[AlamosIT]

Is there a way to prevent mGBA to add these extra RTC bytes? (They could be a problem if people dump and restore save files in their actual game cards)

[endrift]

The whole reason those bytes are there is because there's some state that the cartridges have that isn't saved in the save file. FlashGBX can read/write it in this format. You can just crop them off manually if it's really a problem. I may add a way to export one-off saves without it, but this actually makes importing saves without messing up the in-game time possible--it wasn't before.

@Aerospherology Please answer the question above. Were you using a hacked ROM/non-matching dump?

[LunarLambda]

Maybe a general settings toggle for it would be good too, or a per-game/per-ROM override (those already exist for hw detection iirc?)

[endrift]

To what end? This should be on almost always. The only use case is for interoperability, and in that case a one-off export is better than a shared file that's lossy.

[LunarLambda]

I guess I was thinking ahead to people asking how/why to do this, that it's annoying/etc

But that's not really mGBA's problem to worry about, you're right

[CasualPokePlayer]

Tools generally should just ignore these extra bytes anyways (or at most just warn the user), instead of completely erroring (or better yet supporting them in the case of save restoring tools). It's a footer rather than a header; extra data appended at the end of a normal save.

An export without the bytes is still probably a good idea for bad tools with inactive development, no way for them to be fixed for that. Also would help in cases where the save size is explicitly used to detect save type (most common possible example could be melonDS which would not correctly detect the save type with the added RTC bytes with its current code, although I imagine that can be fixed on their side?).

[socialenigma-og]

That might explain the difference in HIGHSCORE results within Super Mario Advance, upon loading save files between this emulator and NanoBoy Advance...

[CasualPokePlayer]

That game does not have RTC. The issue would be elsewhere.

[endrift]

Closing due to the lack of requested reply from OP.

[MaikelChan]

I'm wondering, would it be an option to have that extra data to an adjacent .rtc file next to the .sav file? Save files would remain clean of extra data and be portable, while the RTC data is still saved for games that need it.