Eeprom in game save fails to load

[eerie-king]

failed to load .srm file example.zip

Description

Emulation of eeprom save game (Boktai in this specific case) plays, is able to save, etc. but if you exit the game and return, you are unable to load the save and returns you to a wiped load screen. If exited to title screen, and load screen re-entered, save is still present, but has same result of failed load.

Issue encountered first with mGBA, but encountered with other GBA cores as well. Attempted to use Retroarch 1.7.3 and game save/load works normally, but if old core is moved to current build of retroarch 1.7.5 the failed load result remains.

Included .srm file used.

Expected behavior

Expected behavior would be for the eeprom save to be able to load while in retroarch normally to resume play.

Actual behavior

eeprom save fails to load when selected and then appears to wipe data, only for it to remain if load screen re-entered.

Steps to reproduce the bug

1. Save game in eeprom save game (Boktai as example)
2. exit game fully.
3. restart core/game.
4. attempt to load saved game

Version/Commit

• RetroArch: 1.7.5
• Git version: 826c77d523
• Build date: Oct 2 2018

Environment information

• OS: Windows 10 Pro - 64 bit

[andres-asm]

Read the:

First and foremost consider this section of the report template.

On Wed, Dec 5, 2018 at 8:21 PM eerie-king notifications@github.com wrote:

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

Emulation of eeprom save game (Boktai in this specific case) plays, is able to save, etc. but if you exit the game and return, you are unable to load the save and returns you to a wiped load screen. If exited to title screen, and load screen re-entered, save is still present, but has same result of failed load.

Issue encountered first with mGBA, but encountered with other GBA cores as well. Attempted to use Retroarch 1.7.3 and game save/load works normally, but if old core is moved to current build of retroarch 1.7.5 the failed load result remains. Expected behavior

Expected behavior would be for the eeprom save to be able to load while in retroarch normally to resume play. Actual behavior

eeprom save fails to load when selected and then appears to wipe data, only for it to remain if load screen re-entered. Steps to reproduce the bug

1. Save game in eeprom save game (Boktai as example)
2. exit game fully.
3. restart core/game.
4. attempt to load saved game

Version/Commit

• RetroArch: 1.7.5
• Git version: 826c77d https://github.com/libretro/RetroArch/commit/826c77d5232142eb0f2b345b01cf494e4e46c125
• Build date: Oct 2 2018

Environment information

• OS: Windows 10 Pro - 64 bit
• Compiler: [In case you are running local builds]

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/7702, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0O065JTaFPQuWblrZznRom87u_leks5u2HEBgaJpZM4ZFoiV .

[eerie-king]

If I've posted in the incorrect area I do apologize and would have to admit ignorance. My understanding of the issue lead me to believe it was an issue with RetroArch as I'd encountered the issue regardless of the core used. I found that the issue is not present in a previous version of RetroArch as well.

Should I still post the issue elsewhere? If so, the direction would be very much appreciated. Sorry for any misunderstanding of course!

[eerie-king]

In discussing issue with others, the possibility of the RTC not being enabled in RA came up. Not certain of the possibility but wanted to include.

[andres-asm]

well it's posted already. Do you have the issue with other games?

Because I have played several GBA games to completion in mgba libretro and I don't have this issue.

[eerie-king]

I have not had the issue with any other games that I've currently been running (about 5 total games on GBA). I generally only use mgba libretro as well. I'd not had any issues with it until I upgraded RA to 1.7.5, as previously i was using the 1.7.3 version. It's only this game that I've encountered the issue with, and I know it has eeprom saving though. Of course not certain if that is the issue.

[eerie-king]

and the saves load in the 1.7.3 version to clarify further.

[andres-asm]

on what platform are you running RetroArch. the RetroArch version hardly ever has anything to do with the core saves.

Edit: Ok, windows, is it the same exact core?

[eerie-king]

Yes the same core. Encountered first with the current mGBA core (mGBA 0.7-b1 6db8583) and and also tried with the older core from 1.7.3 (mGBA 0.7 - wip d98de4a) with RA 1.7.5 and encountered the same issue. Tried both cores in both versions of RA i currently have. Only encountered issue in 1.7.5

[ghost]

this seems like a core issue, or specifically how save data and size are passed to libretro. for this game at least, its suppose to be using 8192 bytes eeprom, but mgba seems to be initializing a 512 bytes save for it hence some bytes are not written when you exit the game (even though after exiting the size becomes 8192 bytes)

from experience, libretro has to already know the size of save ram to use before *retro_get_memory_data/size() call(which happens after retro_load_game() but anywhere before retro_run()), but that hasn't been the case here.

A quick way to confirm this is to force retro_get_memory_size() to return a size of 8192 bytes which the game uses (I've thought mGBA already was padding 512/8192 eeprom saves to use 8192 by default)

[orbea]

@eerie-king Can you use git to bisect between the v1.7.3 and v1.7.5 git tags? Build them both first to make sure you can reproduce the good and bad commits.

[ghost]

@eerie-king Can you use git to bisect between the v1.7.3 and v1.7.5 git tags? Build them both first to make sure you can reproduce the good and bad commits.

to be honest, its got nothing to do with retroarch no matter which tag your in (see my post above)

[orbea]

The git bisect will fail in that case, I think its worth making sure.

[eerie-king]

I'm more than happy to do so, though I would need a quick explanation on how to doso, or just a point in the right direction.

[orbea]

Sure, I can help explain how to accomplish this, but I do not know much about how to set up git or a build environment on windows, can you do this much already?

Assuming yes, first clone RetroArch.

git clone https://github.com/libretro/RetroArch

Now inside the new RetroArch directory, build the master and make sure its still broken.

./configure
make

Assuming its broken, try the v1.7.5 tag next.

# first clean the repo
git clean -xdf

# now checkout the tag
git checkout v1.7.5

# and build it
./configure
make

I'll assume its still broken with this version, now repeat the above with v1.7.3 to make sure it now works again.

# first clean the repo
git clean -xdf

# now checkout the tag
git checkout v1.7.3

# and build it
./configure
make

Assuming this works you can also try v1.7.4 to see if that is a bad or good commit.

Please let me know when you are this far and ask if anything is unclear.

[ghost]

skip to 1.7.3 and see that its still the same issue (just to spare you the hassle)

this was a problem i encountered when working on vbam upstream a few months ago. if you rely on gba to send you size and type of save type used it takes a few cycles before this is known, and most gba emu i see initialized eeprom at 512 bytes since this is the smallest supported. libretro api's get_memory_size/data dont like changing size later especially if this is going to be larger than it started with (that was why vba-next uses padding to set the savefile size to a fixed max 139KB in size) https://github.com/libretro/vba-next/blob/master/libretro/libretro.cpp#L32

either pad the size or use database for those scenarios (which is just about 400+ that using 8192 bytes eeprom as save size)

[eerie-king]

I took a look at git, and I sorry to say its a bit beyond me just in terms of understanding what it is actually if I'm being honest. Like I said i'm happy to do the bisect, but my lack of understanding of it might hold me back. I'm basically coming from position 0. I understand that I'd use git but beyond that not clear.

@retro-wertz i believe you had said off site that you'd been able to replicate the error in v1.7.5 correct? I don't know if you are able/willing to do the bisect on your end, and certainly wouldn't ask to put you out.

Again I'm happy to do it, but from looking at the info I'd really need a step by step "idiots guide." Which is frustrating as I do want to assist with remedying the issue.

[orbea]

I unfortunately lack the knowledge on windows to help you get it set up, once its set up it should be easier to guide you through it.

Basically, step one is to build RetroArch yourself from the source code, you want to check the current master to make sure its not yet fixed, 1.7.3 to make sure that still works and then 1.7.4/1.7.5 to confirm those are still broken.

Using precompiled builds may not give us clear results of where and when the issue first started.

[eerie-king]

I certainly understand. It's more of a case that much of this is outside my bubble of experience so to speak. Git isn't something I'm familiar with, and I couldn't be sure I was doing things correctly, or what I'm attempting to create in the first place honestly. I'm sorry for my inexperience/ignorance on the matter. Unless anyone else is able to assist me, i'll see if I can find some guides.

[eerie-king]

Issue now fixed with current mgba core. Saves working correctly!

[ghost]

actually there are still games having save related issue awhile back in discord for games using flash either that would be fixed from upstream (add probably database for these rare sized games) or libretro itself would allow to re-initialize the save ram if size changes occurs (which is suppose to be possible already by changing the autosave time and then resaving the game) but that should happen realtime.

[Deviljin88]

Please help, my comment Deviljin88 nes Mappers