Drmd Loosing Its Savestates...

[Tetedeiench]

Heya guys,

I'm having trouble with DrMD. I am launching a rom ( for instance, Sonic3), playing a tad, then making a savestate ( L+R to go back in menu, i select "save state", choose slot0, menu says slot is used, perfect, fine).

I can then load it just fine, it works flawlessly.

However, sometimes, when i load back DrMD, it says that no savestate is used... i know somebody which had the same bug, all savestates disappearing.

I have trouble reproducing it though ( sorry reeesy, can't give you more info).

Anyone else has the very same problems ?

 

[Tobriand]

I've certainly got one where a savestate became corrupted after turning the unit off (loaded fine beforehand). But it does definitely still appear to be there... it just crashes DrMD when I try to load it...

 

[Quiest]

It happened to me that I overwrite an older savestate an switched the unit off.
As I wanted to continue the game, I loaded the save state from that slot and it was still the old one, not the new one I saved recently :huh:

Strange things going on!

 

[barnesy]

I've just tried some quick experiments and I think it's a sync issue. It seems to work fine if you exit DrMD properly, but not if you turn the GP2X off while still in the emulator.

Perhaps it's more complicated than that, but I'm guessing that there's something in there to make DrMD commit changes to the SD card when you exit. Maybe it could do that for each write instead? That'd be one for Reesy - it seems right to me but may have other consequences I don't know about.

But yeah - see if you have more success if you make sure you exit the emu properly when you've finished with it.

 

[nik166]

i saved one thing, then when i got back to drmd, it said "read error" when i tried to load the save,


and then, the save was gone

 

[Tobriand]

Yeah, that's probably it... I've always been turning off from the menu. Might also explain the corrupt files from other games as well (most notably, Narcissu).

 

[OCA|]

I've had it happen without powering down the device.

The first time, I went to save state in a game I had saved in once before, on the same slot, overwriting the save, and it simply said "failed" and locked up. This was in Phantasy Star IV

The second time, I was playing Shining Force II and hit L+R to go into the menu. It said "auto-saving SRAM" at the bottom of the screen, and locked up.

I've been really impressed with DrMD so far, but I think I'm going to give it a little more time before I start playing serious RPGs in the thing <_<

-OCA|

 

[declaration]

Yeah, the same happened to me in Shining Force 2.

I have had disappearing savestates as well as currupted save states upon loading.

 

[Reesy]

I've just tried some quick experiments and I think it's a sync issue. It seems to work fine if you exit DrMD properly, but not if you turn the GP2X off while still in the emulator.

Perhaps it's more complicated than that, but I'm guessing that there's something in there to make DrMD commit changes to the SD card when you exit. Maybe it could do that for each write instead? That'd be one for Reesy - it seems right to me but may have other consequences I don't know about.

But yeah - see if you have more success if you make sure you exit the emu properly when you've finished with it.

​

Interesting idea. At the moment I'm just using the standard file system api:

fopen - open file
fwrite/fread - write or read file
fclose - close file

I'm assuming that when I call fclose it should finalise all of the changes and update the file correctly. I never leave a file opened for more than a nano second. I have no idea if there's another linux command I should be using to force an update, maybe there is something you change. I know in WinXP you can change a setting to make removeable media be written to straight away, so you can remove the media as soon as you see the file copy process has ended. Maybe there is something similar in Linux but I have no idea.

 

[Quiest]

Also, my rom directory file got corrupted - It was just displaying weird names Did a rescan and everything was back to normal.

 

[Mysterial]

I'm assuming that when I call fclose it should finalise all of the changes and update the file correctly. I never leave a file opened for more than a nano second. I have no idea if there's another linux command I should be using to force an update, maybe there is something you change. I know in WinXP you can change a setting to make removeable media be written to straight away, so you can remove the media as soon as you see the file copy process has ended. Maybe there is something similar in Linux but I have no idea.

​

I think they have write caching enabled, although I have no idea why. IIRC you can call:

system("sync");

to force it to write the data out.

BTW, pretty much everything I have that saves data out has this problem, including all the other emulators, so don't feel like it's a bug that's specific to yours.

 

[miq01]

Interesting idea. At the moment I'm just using the standard file system api:

fopen - open file
fwrite/fread - write or read file
fclose - close file

I'm assuming that when I call fclose it should finalise all of the changes and update the file correctly. I never leave a file opened for more than a nano second. I have no idea if there's another linux command I should be using to force an update, maybe there is something you change. I know in WinXP you can change a setting to make removeable media be written to straight away, so you can remove the media as soon as you see the file copy process has ended. Maybe there is something similar in Linux but I have no idea.

​

Same behaviour on Tilematch. I noticed that sometimes turning the console off while Tilematch is open doesn't write the hi-scores table to disk, even though I fopen, fwrite, and fclose each time the player gets a high score and enters his/her name. Exiting Tilematch and then turning off seems to work fine.

As Mysterial says, it's probably due to asynchronous writing, so using system("sync"); should do (but I haven't tested it yet), as it turns writing to synchronous.

 

[Quiest]

Yeah I also noticed it for Tilematch, I have to exit for my scores being saved - I lost my best highscore cause of this

Great game, btw ^^

 

[babbagesmachine]

To flush to a file use this its exactly what you want and the normal thing to do when you really need to make sure a file is written now!! rather than when the app closes its a very under used function but applications where data integrity is vital will normaly call it after every write.

Maybe not clear ... fclose does not call fflush it lets the os flush the stream when it wants - which might be straight away or in 1 to whatever seconds, calling fflush causes an interupt (slow in relative terms) and demands the os flush the steam now... therefore call it before fclose to avaid the problem people are haveing

#include <stdio>;
void lba_game_save(void) {
    FILE *file;
    char *save_location;
    asprintf (&save_location, "%s/.lba/saved_state.lba", getenv ("HOME"));//GNU_LINUX printf to allocated string 
    file = fopen(save_location,"wb+");
    if(!file) {
        fprintf (stderr, "Error writting savegame!: %s\n", save_location);
        exit (1);
    }
    free (save_location);//deallocate file location now its been used
    fprintf (file, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
    fflush (file);//flush file
    fclose (file);
}

 

[EvilDragon]

Yep, it's Linux.
Always sync after saving

 

[miq01]

To flush to a file use this its exactly what you want and the normal thing to do when you really need to make sure a file is written now!! rather than when the app closes its a very under used function but applications where data integrity is vital will normaly call it after every write.

Nice... I'll try that.

 

[white]

To flush to a file use this its exactly what you want and the normal thing to do when you really need to make sure a file is written now!! rather than when the app closes its a very under used function but applications where data integrity is vital will normaly call it after every write.

Nice... I'll try that.

​

fclose() will perform fflush() automatically - so your buffered data will be written to the file system. However, that's not the problem - what you really need to do is call sync() after fclose(), which causes all filesystems to flush their writeback caches to the physical device.

http://seth.positivism.org/man.cgi/2/sync

is a link to the man page, but it's just void sync(void); and can be found in unistd.h

 

[white]

To flush to a file use this its exactly what you want and the normal thing to do when you really need to make sure a file is written now!! rather than when the app closes its a very under used function but applications where data integrity is vital will normaly call it after every write.

Nice... I'll try that.

​

fclose() will perform fflush() automatically - so your buffered data will be written to the file system. However, that's not the problem - what you really need to do is call sync() after fclose(), which causes all filesystems to flush their writeback caches to the physical device.

http://seth.positivism.org/man.cgi/2/sync

is a link to the man page, but it's just void sync(void); and can be found in unistd.h

​

Oh, forgot to mention that you can download a .gpu script which will do the same thing. Just run it after leaving your emulator and before switching off the gp2x and your savestate will be fine.

http://www.gp32x.de/board/index.php?showtopic=22938

 

[Quiest]

Sweet, thanks!

 

[TwoHeadedBoy]

Hallelujah, I go away for a couple of days and come back to find DrMD ready!
Just downloaded it now, gonna have some fun. Will also have to change my sig