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 ?
Full Version: Drmd Loosing Its Savestates...
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...
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
Strange things going on!
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
Strange things going on!
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.
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.
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
and then, the save was gone
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).
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|
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|
Yeah, the same happened to me in Shining Force 2.
I have had disappearing savestates as well as currupted save states upon loading.
I have had disappearing savestates as well as currupted save states upon loading.
QUOTE(barnesy @ Dec 12 2005, 10:41 AM)
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.
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.
Also, my rom directory file got corrupted - It was just displaying weird names 
Did a rescan and everything was back to normal.
Did a rescan and everything was back to normal.
QUOTE(Reesy @ Dec 12 2005, 08:42 AM)
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.
QUOTE(Reesy @ Dec 12 2005, 03:42 PM)
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.
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.
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 ^^
Great game, btw ^^
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);
}
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 CODE
#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);
}
Yep, it's Linux.
Always sync after saving
Always sync after saving
QUOTE(babbagesmachine @ Dec 12 2005, 06:34 PM)
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.
QUOTE(miq01 @ Dec 12 2005, 04:59 PM)
QUOTE(babbagesmachine @ Dec 12 2005, 06:34 PM)
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
QUOTE(white @ Dec 12 2005, 05:49 PM)
QUOTE(miq01 @ Dec 12 2005, 04:59 PM)
QUOTE(babbagesmachine @ Dec 12 2005, 06:34 PM)
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.com/board/index.php?showtopic=22938
Sweet, thanks!
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
Just downloaded it now, gonna have some fun. Will also have to change my sig
Thanks for all the advice, sync() will now be appearing in a DrMD near you. I might get chance to fix this and a couple of other bugs tonight. I'll let you all know
You didn`t fix the flickering menu yet, no? Just asking because you said it`s much work...
Nah I haven't implemented quad buffering in 16bit mode yet, in fact I've not touch DrMD since the last release. I was suffering a bit of burnout so I've had a couple of days off. Might get some stuff done though
QUOTE(white @ Dec 12 2005, 07:49 PM)
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.
Just to confirm that it works. I opened Tilematch, played for one minute, saved my score, and immediately after that, I turned GP2X off without quitting. After starting again, that score was there. Thanks!
QUOTE(Tetedeiench @ Dec 12 2005, 02:13 AM)
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 ?
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 ?
First off, why are you using Savestates with Sonic 3? I'm pretty sure that ROM can save onto itself, no save state required. (If it's not a dirty rom that is)
Because you would have the same problem. I never use sync(), so even after saving a sram file, if you switch the gp2x before linux decides to actually write the file to disk you will be buggered.
I've just tested sync and it looks like it fixes the problem. I'll release another version a bit later then you lot can do your worst to it
I've just tested sync and it looks like it fixes the problem. I'll release another version a bit later then you lot can do your worst to it
i hope you can get to fixing the menu thing sometime soon, it gets very distracting, and the savestate thing, i lost my save for gunstar heroes because of that had the game almost beat too. but drmd is simply awesome and keep up the great work man! if i had any money i would donate some to ya!
had the game almost beat too. but drmd is simply awesome and keep up the great work man! if i had any money i would donate some to ya!
QUOTE(God Ginrai @ Dec 12 2005, 10:38 PM)
QUOTE(Tetedeiench @ Dec 12 2005, 02:13 AM)
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 ?
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 ?
First off, why are you using Savestates with Sonic 3? I'm pretty sure that ROM can save onto itself, no save state required. (If it's not a dirty rom that is)
Because i'd rather loose a sonic3 savestate than a Story of thor
that's the reason why I'm happy this is fixed
QUOTE(Reesy @ Dec 12 2005, 10:41 PM)
Because you would have the same problem. I never use sync(), so even after saving a sram file, if you switch the gp2x before linux decides to actually write the file to disk you will be buggered.
I've just tested sync and it looks like it fixes the problem. I'll release another version a bit later then you lot can do your worst to it
I've just tested sync and it looks like it fixes the problem. I'll release another version a bit later then you lot can do your worst to it
I think we ought to put a reminder to call sync() after fclose() somewhere in the development help docs...
Reesy, the new DrMD version is solving the problem... working great great great !
Love you
Love you
I can not get over how great Dr MD is now!!!!
Brian.....
Lara's......
T..h..a..n..k..y..o..u......
Now write me a snes emu, you naughty, beautiful boy!!!!
Brian.....
Lara's......
T..h..a..n..k..y..o..u......
Now write me a snes emu, you naughty, beautiful boy!!!!
I wonder why GPH didn't mount the SD with the "-o sync" option. That would have avoided all these problems.
Anyway, great job Reesy
Anyway, great job Reesy
QUOTE(FluffyPanda @ Dec 13 2005, 02:07 PM)
I wonder why GPH didn't mount the SD with the "-o sync" option. That would have avoided all these problems.
Anyway, great job Reesy
Anyway, great job Reesy
Probably too slow for random access to the drive; and they don't have an infinite amount of read/write cycles as far as I can recall. But what they definitely should have done is put a call to sync() at the start of the launcher, so when it gets reinvoked at the end of an application it syncs automatically.
Hmmm (thinks)... one could theoretically replace the launcher with a script which does sync() and then calls the old, real launcher. But if you did it wrong you'd brick the gp2x
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.