Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug][PS1] BizHawk NOT writing SaveRAM to DISK, IF a SaveState is saved after an in game save is saved.. BUFFER is wiped/CLEARED?! #1031

Closed
MelchiorGaspar opened this issue Oct 22, 2017 · 20 comments

Comments

Projects
None yet
3 participants
@MelchiorGaspar
Copy link

commented Oct 22, 2017

File Name: Final Fantasy Tactics (USA)(NTSC)(SCUS94221).cue/bin
BizHawk HASH: 377F6510 (verified good dump)

regardless if .SaveRAM even exists before hand if I save to memory card in game and acts like it takes it..
BUT BizHawk's PS1 is still NOT writing a .SaveRAM file to DISK... for this game...

There are no special steps... beyond basic/usual ones..

  1. load BizHawk
  2. load game "Final Fantasy Tactics" in format bin/cue BizHawk verifies as a good dump..
  3. start a new game or load a save-state..
  • Load a NEW GAME, and get to the first save point at the stat of Chapter 1..
    -- save (no .SaveRAM created), Close ROM (no .SaveRAM created), Exit BizHawk (no .SaveRAM created)...

  • but if loading a save state, it thinks there is already a save on memory card but in truth its a copy of the save in memory, that is/was stored in the Save State..
    which is not really a good idea.. as it can overrule saves actually in memory card on DISK :P ..
    in my case I deleted the FFT .SaveRAM file... and

BizHawk DOES NOT create a new .SaveRAM file when I,

  • Save in-game,
  • Close ROM,
  • OR exit BizHawk!

if I save after loading a savestate, save in-game, then do a soft reset...
the save is there still in memory..
but again there is NO physical .SaveRAM present on DISK.. or is CREATED.. :-/

ok one item some times missed.. my system specs via a

and my BizHawk settings files..
BizHawk's CONFIG FILES.zip

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

Tried this with Suikoden 1 as well.
File Name: Suikoden 1 (USA)(NTSC)(SLUS00292)(v1.1).cue/bin
BizHawk HASH: E0DF06E0 (verified good dump)

The save copied to the BizHawk generated .SaveRAM file using rex, is detected and loads just FINE!
I re-save to update the in-game save..

  • no immediate write write to DISK....
  • Close ROM no write write to DISK....
  • and last EXIT BizHawk... NOPE BizHawk is NOT writing to DISK for Suikoden 1 either...

and both games are GOOD dumps...

=/ >_>

and since both games have already loaded once they are on the Recent ROM list...
which is where I have loaded both games from... if that could be an issue...

another thing... of these two games tested so far..
only Suikoden 1 is starting paused.. for some odd reason. ?_?
to make sure this was not the issue.. I loaded S1 from Open ROM menu item..
no change...

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2017

Works fine for me and everyone else. SaveRAM is created when rom or emulator is closed, as normal.
You have a problem with your config.ini file (delete it and let it recreate) or with your disk permissions (try running bizhawk from a folder on your desktop)

@zeromus zeromus closed this Oct 22, 2017

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

or with your disk permissions

lol NOT a chance I keep my emu stuff on a server HDD with set FULL permissions..
so that is NOT it... ;) :P
permissions on ALL folders check out... FULL.

what does this do?

  • "EnableLEC": false
    under.. ."BizHawk.Emulation.Cores.Sony.PSX.Octoshock":

and I have enabled

  • Back Saveram
    but only the Save States are being saved/written to disk and backed up...
    the memory card files are not only NOT being saved at all. they are not being backed up either...

by clicking on

  • FILE --> Save RAM --> Flush Save Ram
    the memory card file was created... but still no go on saving..
    its not even reading the damn file on run of the game image or when I try to load a save from in game...
    I next did a Flush Save Ram after the save state was loaded... no go.. still not reading or writing to PS1 SaveRAM files.. or so it appeared.. I saved in game again.. then Closed the ROM and restarted..
  • ooh the save was there.. as it should be... hmm....
    next I exited BizHawk.. and restarted it... save seems to be there..

BUT I saved again a few minutes later...
Close the game then exit out of BizHawk..
again no write to file...

there is definitely a BUG going on here of some kind..
I have tried the v4.5 and v4.1 BIOS files verified good dumps..
no difference..

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

Genesis and SNES .SaveRAM reading and writing are working!
So its just the PS1 emu core that is not...

have your backed up your ini and tried mine to really see if that is the case?

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2017

There's (probably?) no automatic write to the file unless the data has changed.

Back(up) Saveram is enabled by default.
They won't be backed up if your system has a permissions issue and it can't write the saverams either. Maybe your security software is interfering? If it's not permissions issues, then it sounds a lot like security software interference.

I don't understand "no go on saving".

I don't know how you're determining that it's "not even reading the damn file" at time X or time Y, but if you're trying to be smart and watch the filesystem activity, you'll be misled. The file is read when the disc image is loaded. Maybe you're completely confused by that, and that explains everything.

EnableLEC controls bad sector error correction. It has nothing to do with saving.

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2017

No, I didnt try your ini, because I told you to delete your ini.

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

I just deleted the ini and am redoing it now...

each file Properties in Windows has three main times..
Created, Modified, and accessed..
‎Today, ‎October ‎22, ‎2017, ‏‎1 hour ago was the last time accessed for the FFT SaveRAM file..

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

I have redone ALL my settings.. from scratch.. NO CHANGE! =/ >_>

Final Fantasy Tactics (USA).SaveRAM
Last Modified: ‎Today, ‎October ‎22, ‎2017, ‏‎5:07PM
Last Accessed: Today, ‎October ‎22, ‎2017, 4:49PM

and the only modify was done by the Flush Save Ram and save right after it... =/

when loaded save from memory card.. it should change the accessed time..
it didn't so where is getting the in game save from?... =/

Final Fantasy Tactics (USA).SaveRAM
I tried saving several times rebooting etc..
its not saving to file.. except for SaveStates..

like I said SNES and Genesis RAM and States are working as they should be..

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 22, 2017

I will try the my original BIOS file:

  • PS1 BIOS File (SCPH-1001)(v2.2)(12-04-1995)(NTSC-USA)(My Model PS1).bin

NOPE its not the BIOS either..
BizHawk is STILL NOT saving PS1 SaveRAM files...

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2017

You were supposed to delete your ini file; not delete your ini file and then redo all your settings.

When you load the save from the memory card it SHOULD NOT change the access time. The memory card file is accessed when the rom is loaded.

The memory card file may only be written when the contents have changed

Besides that, the last access time is not reliable. Use process monitor to discern when the file is updated.

The BIOS has nothing to do with this.

Your misconceptions or non-standard configurations have to do with this.

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 25, 2017

OK meh.. I tried again...
this time with minimum settings redone..

  • BIOS selection..
  • PATHS (I change the paths to "__ConsoleName" to group them all together at the top of the directory
    for a neater layout ;) )
  • Hotkeys
  • Controller layout..

Surprisingly PS1 SaveRAM is WORKING... O_o

not to find out were or what setting is messing it up this is STILL likely a bug...
DUH! so please reopen this "I" will close it when I am done and this matter has been resolved.!

OK, next I changed ONE thing/setting..
in the status bar there is an icon of "Set up profile"..
opened it up and it is set to casual gamer.. I ok'd it and saved ini..
next loaded FFT again... loaded save, saved again, closed game, and FILE was updated! like it should.
so that wasn't it either...

NOTE: that BizHawk is still set to default SaveState selection, ie State #0
Next I tested the SaveStates..
my above config modified the SaveState hotkeys as follows
Saving State 1 = F1
Loading State 1 = F4

reconfigured:
Saving State #4 = SHIFT+F4
Loading State #4 = CONTROL+SHIFT+F4
that gets it out of the way...

I tested again.. to see if it was a config issue.. of having the State 4 slots Save/load Hotkeys not set..

load FFT again, LOAD save again,
OK meh.. I tried again...
this time with minimum settings redone..

  • BIOS selection..
  • PATHS (I change the paths to "__ConsoleName" to group them all together at the top of the directory
    for a neater layout ;) )
  • Hotkeys
  • Controller layout..

Surprisingly PS1 SaveRAM is WORKING... O_o

not to find out were or what setting is messing it up this is STILL likely a bug...
DUH! so please reopen this "I" will close it when I am done and this matter has been resolved.!

OK, next I changed ONE thing/setting..
in the status bar there is an icon of "Set up profile"..
opened it up and it is set to casual gamer.. I ok'd it and saved ini..
next loaded FFT again... loaded save, saved again, closed game, and FILE was updated! like it should.
so that wasn't it either...

Next I tested the SaveStates..
NOTE: that BizHawk is still set to default SaveState selection, ie State #0
my above config modified the SaveState hotkeys as follows
Saving State 1 = F1
Loading State 1 = F4
State 4 load/save is = blank, then tested again..

load game, load save, save game,
THIS time I SAVED State #1 using F1 which AUTO switched the state selection from #0 to #1,
closed game, BINGO IT DID NOT WRITE SaveRAM to DISK!!!

next test, manually switched the SaveState to Slot #1 from Slot #0 first before saving...
Load FFT, load save, save game, Switch save slot from #0 to #1, hit F1 to save slot #1,
hit F1 to save slot #1, close game, SaveRAM is NOT written to HDD O_o lol.
sub-conclusion: the changing of SaveState slots is NOT the issue...

NEXT I configured:
Saving State #4 = SHIFT+F4
Loading State #4 = CONTROL+SHIFT+F4
to test if having the hot keys empty was causing an issue..
Load FFT, load save, save game, F1 to SaveState1 including auto switch of state from 0 to 1,
SaveRAM NOT saved to HDD... so empty hotkeys not an issue..

next test.. removing/deleting all SaveStates first to see if its an issue with existing saves....
then retesting..
I did a quick save and close test...
SaveRAM IS written to DISK!
so it appears as though SaveState saving is interfering with SaveRAM file writing!!

NEXT tried loading FFT, load save, SAVE SaveState1 first, THEN I saves in game save, closed game..
LOL WOW SaveRAM FILE written to DISK...
So Saving a SaveState AFTER doing a in game save IS interfering with the SaveRAM save operation
AFTER ALL.. so THERE is a BUG..

Solution debug and FIX in BizHawk's fork of OctoCore THEN send the fix upstream to the OctoCores's
main devs..

This being the CASE please reopen this issue ticket!

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 25, 2017

NEXT I placed config.ini with my old FULLY configured one.. and retested..
saving game without making a SaveState save: DID NOT save SaveRAM to disk.. strange???? :-/
saving game after making a SaveState save: DID NOT save SaveRAM to disk again.. this is so weird..
making a SaveState save after an in game save: NOPE of course not...
for these the SaveState slot was already set to slot 1, when the save occurred..

I will do a quick test, switch it back to slot 0 then save slot 1 as I just did above..
saving game without making a SaveState save: nope
so slot number again is not the issue...

I will you Tortoise Merge to do a difference test of the working ini and the failing ini...

BINGO, FOUND one of the differences is I had

  • Medium and Large rewind states were enabled/set..
    so I disabled medium and large after PS1 game was loaded.. status says rewinds disabled..
    SaveRAM saves to disk.!! O_o

I next tested as above, this time with rewinds disabled:
saving game without making a SaveState save: SaveRAM written to HDD!
saving game after making a SaveState save: SaveRAM written to HDD! lol ;) :D
making a SaveState save after an in game save: YUP DOES NOT save SaveRAM to HDD!

so its partially the rewind system as well as the SaveState system causing an issue with
SaveRAM/MemoryCard writing...


next TEST, load console and see if it spits out a warning or error message when doing a SaveState after saving in game... had to restart BizHawk first as nothing was displaying in the console at first...
various bits of startup info...

load game:
HawkFile bound F:\EmulatorsRoms\PS1\CDImages\Final Fantasy Tactics (USA)(NTSC)(SCUS94221).cue
Active Firmwares:
U : DCFFE16BD90A723499AD46C641424981338D8378
PSX FB size: 280,240

load save: no info in log.
save game: no info in log.
Save SaveState: Elapsed time for Save Core: 32ms
close game: no info in log.
so nothing really helpful X_x :(

saved game and closed without saving SaveState: No info in log

NEXT I ran BizHawk through the GNU Debugger (gdb.exe) as part of MinGW for Windows..
32bit apps.. I have TDM-gcc for 64&32bit as well.. ;)

loaded game, saved game, saved SaveState, closed game...
for loading and saving.. a few new threads were created and logged...

HOWEVER!
When I did a SaveState I got the following WARNINGS:

warning: `C:\Windows\assembly\NativeImages_v4.0.30319_64\System.IO.Cb3b124c8#\acd2402e8b2e817f6065c839ecc36e4e\System.IO.Compression.ni.dll':
Shared library architecture i386:x86-64 is not compatible with target architecture i386.

warning: `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrcompression.dll':
Shared library architecture i386:x86-64 is not compatible with target architecture i386.
[New Thread 4280.0x1300]
[Thread 4280.0x1300 exited with code 0]


and when I closed the game... nothing new logged...
and I shutdown BizHawk next.. all threads exited.. nothing out of the usual...
and attached is the full log file I had gdb dump..
and there are a lot of these logged..

Shared library architecture i386:x86-64 is not compatible with target architecture i386.

of these note worthy are:

Starting program: F:\EmulatorsRoms_BizHawk\EmuHawk.exe
warning: F:\EmulatorsRoms\_BizHawk\dll\octoshock.dll': warning: F:\EmulatorsRoms_BizHawk\dll\SlimDX.dll

ALL the rest are related to Windows and .NET framework...


idk.. is there other issues with OctoCore..
it has to be a bug...
NEXT I placed config.ini with my old FULLY configured one.. and retested..
saving game without making a SaveState save: DID NOT save SaveRAM to disk.. strange???? :-/
saving game after making a SaveState save: DID NOT save SaveRAM to disk again.. this is so weird..
making a SaveState save after an in game save: NOPE of course not...
for these the SaveState slot was already set to slot 1, when the save occurred..

I will do a quick test, switch it back to slot 0 then save slot 1 as I just did above..
saving game without making a SaveState save: nope
so slot number again is not the issue...

I will you Tortoise Merge to do a difference test of the working ini and the failing ini...

BINGO, FOUND one of the differences is I had

  • Medium and Large rewind states were enabled/set..
    so I disabled medium and large after PS1 game was loaded.. status says rewinds disabled..
    SaveRAM saves to disk.!! O_o

I next tested as above, this time with rewinds disabled:
saving game without making a SaveState save: SaveRAM written to HDD!
saving game after making a SaveState save: SaveRAM written to HDD! lol ;) :D
making a SaveState save after an in game save: YUP DOES NOT save SaveRAM to HDD!

so its partially the rewind system as well as the SaveState system causing an issue with
SaveRAM/MemoryCard writing...


next TEST, load console and see if it spits out a warning or error message when doing a SaveState after saving in game... had to restart BizHawk first as nothing was displaying in the console at first...
various bits of startup info...

load game:
HawkFile bound F:\EmulatorsRoms\PS1\CDImages\Final Fantasy Tactics (USA)(NTSC)(SCUS94221).cue
Active Firmwares:
U : DCFFE16BD90A723499AD46C641424981338D8378
PSX FB size: 280,240

load save: no info in log.
save game: no info in log.
Save SaveState: Elapsed time for Save Core: 32ms
close game: no info in log.
so nothing really helpful X_x :(

saved game and closed without saving SaveState: No info in log

NEXT I ran BizHawk through the GNU Debugger (gdb.exe) as part of MinGW for Windows..
32bit apps.. I have TDM-gcc for 64&32bit as well.. ;)

loaded game, saved game, saved SaveState, closed game...
for loading and saving.. a few new threads were created and logged...

HOWEVER!
When I did a SaveState I got the following WARNINGS:

warning: `C:\Windows\assembly\NativeImages_v4.0.30319_64\System.IO.Cb3b124c8#\acd2402e8b2e817f6065c839ecc36e4e\System.IO.Compression.ni.dll':
Shared library architecture i386:x86-64 is not compatible with target architecture i386.

warning: `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrcompression.dll':
Shared library architecture i386:x86-64 is not compatible with target architecture i386.
[New Thread 4280.0x1300]
[Thread 4280.0x1300 exited with code 0]


and when I closed the game... nothing new logged...
and I shutdown BizHawk next.. all threads exited.. nothing out of the usual...
and attached is the full log file I had gdb dump..
and there are a lot of these logged..

Shared library architecture i386:x86-64 is not compatible with target architecture i386.

of these note worthy are:

Starting program: F:\EmulatorsRoms_BizHawk\EmuHawk.exe
warning: F:\EmulatorsRoms\_BizHawk\dll\octoshock.dll': warning: F:\EmulatorsRoms_BizHawk\dll\SlimDX.dll

ALL the rest are related to Windows and .NET framework...

BizHawk_gdb-logging(2017-10-25__08-41-13).log.txt


IT has to be a bug...
in either

  • Windows,
  • MS .NET,
  • BizHawk, or
  • OctoCore

as SaveRAM and SaveStates for other Consoles do not appear to be affected...
will do a quick test... of SNES and Genesis..
load ROM, save game, SaveState, close ROM:


gdb log warning on SNES & Genesis ROM loading BUT NOT on a PS1 CD-Image load.. O_o:

[Thread 6924.0x16ec exited with code 0]
warning: `C:\Windows\system32\bcrypt.dll':
Shared library architecture i386:x86-64 is not compatible with target architecture i386.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()

  • C:\Windows\system32\bcrypt.dll =

  • Windows Cryptographic Primitives Library (6.1.7601.23915 (win7sp1_ldr.170913-0600))

  • C:\Windows\SysWOW64\bcrypt.dll =

  • Windows Cryptographic Primitives Library (Wow64)(6.1.7601.23915 (win7sp1_ldr.170913-0600))


gdb log ALSO logged these warnings when I did a SaveState for SNES & Genesis games as well
as PS1/OctoCore as I mentioned above...:

[New Thread 7136.0x1228]
warning: `C:\Windows\assembly\NativeImages_v4.0.30319_64\System.IO.Cb3b124c8#\acd2402e8b2e817f6065c839ecc36e4e\System.IO.Compression.ni.dll':
Shared library architecture i386:x86-64 is not compatible with target architecture i386.

warning: `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrcompression.dll':
Shared library architecture i386:x86-64 is not compatible with target architecture i386.
[Thread 7136.0x192c exited with code 0]



So.. its only PS1 SaveState saving that is effecting the PS1 SaveRAM/MemoryCard
write to HDD... O_o X_x

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 25, 2017

I will TEST with Process Monitor next and report back...

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 25, 2017

using Process Monitor I have got a ton of data to sift though...

OK this is what I digged out of a Stack Trace with reference to SaveRAM:

<Process_Name>EmuHawk.exe</Process_Name>
<PID>4248</PID>
<ProcessIndex>230</ProcessIndex>


<Time_of_Day>9:36:25.9310888 AM</Time_of_Day>
<Operation>QueryOpen</Operation>
<Path>F:\EmulatorsRoms\_BizHawk\__PSX\SaveRAM\Final Fantasy Tactics (USA).SaveRAM</Path>
<Result>SUCCESS</Result>
<Detail>
CreationTime: 10/22/2017 4:49:30 PM, 
LastAccessTime: 10/22/2017 4:49:30 PM, 
LastWriteTime: > 10/25/2017 8:39:09 AM, 
ChangeTime: 10/25/2017 8:39:09 AM, 
AllocationSize: 262,144, 
EndOfFile: 262,144, 
FileAttributes: A
</Detail>


next: 
<Time_of_Day>9:36:25.9327964 AM</Time_of_Day>
<Operation>CreateFile</Operation>
<Path>F:\EmulatorsRoms\_BizHawk\__PSX\SaveRAM\Final Fantasy Tactics (USA).SaveRAM</Path>
<Result>SUCCESS</Result>
<Detail>
Desired Access: Generic Read, 
Disposition: Open, 
Options: Synchronous IO Non-Alert, Non-Directory File, 
Open No Recall,
Attributes: n/a, 
ShareMode: Read, 
AllocationSize: n/a, 
OpenResult: Opened
</Detail>

next:
<Time_of_Day>9:36:25.9328310 AM</Time_of_Day>
<Operation>ReadFile</Operation>
<Path>F:\EmulatorsRoms\_BizHawk\__PSX\SaveRAM\Final Fantasy Tactics (USA).SaveRAM</Path>
<Result>SUCCESS</Result>
<Detail>
Offset: 0, 
Length: 262,144, 
Priority: Normal
</Detail>


LAST SaveRAM reference entry: 
<Time_of_Day>9:36:25.9329712 AM</Time_of_Day>
<Operation>CloseFile</Operation>
<Path>F:\EmulatorsRoms\_BizHawk\__PSX\SaveRAM\Final Fantasy Tactics (USA).SaveRAM</Path>
<Result>SUCCESS</Result>
<Detail></Detail>

NEXT I will search for references to SaveStates and see what I can dig up...
then I will post an archive with all of the log files in it if its NOT too bug otherwise
I will host it on my Dropbox account and link it here lol ;) :D

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2017

The bug is reproducible without your walls of text. You can stop debugging.

  1. Clean test
  2. Boot game, wait for FMV
  3. Check file menu; save ram is bolded (everything is working)
  4. Clean test
  5. Enable rewind for large states
  6. Boot game, wait for FMV
  7. Check file menu; save ram is NOT bolded--the detection for ditrty save ram hasb een broken
@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 25, 2017

lol ;) :P
and my next WALL of data is SOOO VERY LONG TOO lol ;-P
ok..
ooh O_o..
but it occurs while Rewind is OFF too.. but only when saving a SaveState after saving in game..
otherwise a SaveState save first then a save in game SaveRAM file writes fine then...

What exactly does "Flush Save Ram" do?
Does it force a write to DISK? OR does it simply WIPE clean the BUFFER? or both?
because I think it updated the modified time one time I tried it..

OK I think I see or get it now..

  1. in game save is made, to SaveRAM buffer in memory..
    "Flush Save Ram" becomes BOLD to indicate as such..

  2. Save a SaveState(#1)
    "Flush Save Ram" is no longer BOLD
    so the buffer was/is

  • CORRUPTED?
  • WIPED/CLEARED without writing to DISK?
    because the in RAM buffer for the SaveState was cleared after writing to DISK?
    so maybe its accidentally clearing the SaveRAM buffer too?

SEE I DID find/REPORT a BUG!
lol :-P
TOLD YA! lol ;-)
How about reopening this now? lol ;-)

@MelchiorGaspar MelchiorGaspar changed the title [Issue/bug?][PS1] Bug with BizHawk NOT writing .SaveRAM to DISK for Final Fantasy Tactics.. [bug][PS1] BizHawk NOT writing SaveRAM to DISK, IF a SaveState is saved after an in game save is saved.. BUFFER is wiped/CLEARED?! Oct 25, 2017

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2017

After making a savestate, the dirty flag is cleared, so it doesn't think there's any data to save.

This is a result of trying to make the PSX core different from every other core, as an experiment: it was meant to give the user more information about whether the game has edited the save data, so he can make a more intelligent choice about when to manually flush the save data.

Most cores consider the saveram dirty all the time; so when you load the state, and then close the emulator, the dirty save ram will write out even though the user hasn't saved in-game. You've previously mentioned you dont like this; however there are reasons it should be this way (for some consoles there's absolutely no clear way to know if the user has saved in-game) and it won't be changing*

With PSX, the saveram (as an experiment) is considered only dirty when actually dirtied. This way when closing the program, the save memory will only get flushed when the user has saved in-game. However--it isnt foolproof (some games can edit save memory without you thinking you've "saved in-game").

*However it will become irrelevant, because I plan to eliminate ALL AUTOMATIC FLUSHING of save ram in the future. This is why I made the PSX core work differently, as an experiment to see if we could get useful feedback to the user about when he should flush his save ram.

Anyway, there's a bug in my special PSX logic that cleared the dirty flag when saving the state which makes no sense.

For the historical record, here's an easier way to confirm the bug

  1. On a clean emulator, fastforward FFT to the cutscene
  2. Confirm file menu is bold
  3. Savestate
  4. Confirm file menu is NO LONGER BOLD (that's the bug)

@zeromus zeromus reopened this Oct 25, 2017

@zeromus zeromus closed this in e64d00b Oct 25, 2017

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 25, 2017

You've previously mentioned you dont like this;

oohh? You don't say? lol where did I say that? lol :-P

I have "SRAM CHECK+SAVE" = enabled in ZSNES,
which keeps an eye on the SaveRAM buffer in memory..
when it detects a save was made,
it immediately writes the save to the .srm file..
or at least I think that is how it works...

so yeah I like that feature...
and with regards to SaveStates..
they should be independent shouldn't they?
that way a load of a SaveState does no overwrite the SaveRAM..
destroying in game saves in buffer or in file...
in case of jumping around with different SavesStates...

need to revisit it on the date of the great automatic-flushing-deprecation.

ooh? sounds sad or a bad idea... it is a must to make saves to disk when the occur...
it happens immediately when a SaveState is done so it should be too with SaveRAM buffer/file

BECAUSE you CANNOT count on BizHawk getting to the close game point or WORSE crashing of course!
in which case the saves made in game would be TOTALLY LOST... :-(

I love find bugs and reporting them ;-) :-)

zsnes_config-screenshot_config_save options

@zeromus

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2017

"but if loading a save state, it thinks there is already a save on memory card but in truth its a copy of the save in memory, that is/was stored in the Save State..
which is not really a good idea.."

And you mentioned it again now:

"and with regards to SaveStates..
they should be independent shouldn't they?
that way a load of a SaveState does no overwrite the SaveRAM..
destroying in game saves in buffer or in file...
in case of jumping around with different SavesStates..."

No, they should not be independent. They are not independent in MOST EMULATORS. For the sake of that alone, they should not be independent. But the specific reason, I explained: we can't always know when the user has saved in-game. In that case, some games will flush immediately after loading a state, because the emulator mistakenly thinks the user saved in-game. Other games will not flush immediately after loading a state--so the user will never know, and it will seem unpredictable. This is not negotiable and you will never convince anyone otherwise who already believes otherwise.

As far as my "manual flushes only" being a problem due to bizhawk crashing: the same problem exists right now. If the user saves in-game and bizhawk crashes before you close the rom, or the emulator, then the saveram will be lost. So it's no change.

The only change with my "manual flushes only" is now exiting the emulator will no longer automatically flush saverams. (But we'll ameliorate this by extending the automatic saveram backups features and enabling them by default).

We won't be implementing zsnes's "checksrm+save" function any time soon. That really requires support from each core to know when the save ram is dirty, and that can't be known easily or at all in many cases. The payoff would be little. But for cores like PSX where it can be known, it might be useful.

@MelchiorGaspar

This comment has been minimized.

Copy link
Author

commented Oct 25, 2017

But for cores like PSX where it can be known, it might be useful.

ok do it "some day" if you can ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.