07-19-2013, 09:30 AM
I recently made a move from WinXP to Win7. r3189 worked well back with XP and works on Win7 just as well.
Since I have a x64 computer now, I tried the latest x64 revsion(r3315).
Now whenever I load up a game(VC2[ULUS10515] and VC3[NPJH50343]), I get notified that the savedata is corrupt(the same savedata works fine for r3189).
Then I tried with the 32-bit r3315 => same result.
After that, I tried to let the game create a new savegame, but even that new savegame was considered to be corrupted when trying to load. And everytime I let the game delete the newly created corrupted savegame, the emulator goes into endlessly trying to delete something(Savedata MODE_SINGLEDELETE directory not found) after deleting all the files that were created before.
So neither the 32-bit nor the 64-bit r3315 can load my saves from r3189(they were created and used without the crypto-mode) and they can't create new(non-corrupt) savegames as well(the folder and files are created though). Changing to cryto-mode leads to the exact same result.
I don't think the problem is file-system related, since the DLC-data seems to load just fine.
Anyone got an idea what might cause this/how to fix this?
EDIT: r3304 seems to bee the last revision where loading my savegames doesn't result in the claim of "corrupted data"(i guess r3305 would still work if not for the incomplete build). I have he suspicion that the changes introduced in r3306 are the cause for this.
EDIT2: I've confirmend my suspicion. After a rollback to the last version for all the files modified by r3306 loading and saving work again. I think I'll try putting stuff back in litte by little and see what happens.
EDIT4: I now know that whatever breaks loading/saving is in HLE/modules150/sceUtility.java. I'll try modifing that code to make it work.
EDIT5: I think I have the problem: The savefiles I have are secure files[if (saveFileSecureEntriesAddr != 0) results in true]. Furthermore if(saveFileEntriesAddr != 0) results in a false-value. That alone would be no problem but with the new implementation, there is a if(savedataParams.isSecureFile(entry)) check before checking if we have a value for saveFileSecureEntriesAddr. And that check returns a false.
So I took a closer look to the isSecureFile() function. Said function accesses this value: psf.get("SAVEDATA_FILE_LIST"), which is not set for my savefiles.
What exactly is this SAVEDATA_FILE_LIST and why is it suddenly needed, even though things seem to work without it(at least for my saves)?
EDIT6: I forgot to mention, I had to change mem.write64(entryAddr + 8, ((stat.size + 0xF) & ~0xF) - 0x10); back to mem.write64(entryAddr + 8, stat.size); for things to work. What was that change supposed to do?
So now that I found a way to make saving/loading work for me again, could you explain what SAVEDATA_FILE_LIST and ((stat.size + 0xF) & ~0xF) - 0x10) are supposed to be doing gid15? Any idea why that changes made it impossible to load savegames for VC2[ULUS10515] and VC3[NPJH50343]?
Since I have a x64 computer now, I tried the latest x64 revsion(r3315).
Now whenever I load up a game(VC2[ULUS10515] and VC3[NPJH50343]), I get notified that the savedata is corrupt(the same savedata works fine for r3189).
Then I tried with the 32-bit r3315 => same result.
After that, I tried to let the game create a new savegame, but even that new savegame was considered to be corrupted when trying to load. And everytime I let the game delete the newly created corrupted savegame, the emulator goes into endlessly trying to delete something(Savedata MODE_SINGLEDELETE directory not found) after deleting all the files that were created before.
So neither the 32-bit nor the 64-bit r3315 can load my saves from r3189(they were created and used without the crypto-mode) and they can't create new(non-corrupt) savegames as well(the folder and files are created though). Changing to cryto-mode leads to the exact same result.
I don't think the problem is file-system related, since the DLC-data seems to load just fine.
Anyone got an idea what might cause this/how to fix this?
EDIT: r3304 seems to bee the last revision where loading my savegames doesn't result in the claim of "corrupted data"(i guess r3305 would still work if not for the incomplete build). I have he suspicion that the changes introduced in r3306 are the cause for this.
EDIT2: I've confirmend my suspicion. After a rollback to the last version for all the files modified by r3306 loading and saving work again. I think I'll try putting stuff back in litte by little and see what happens.
EDIT4: I now know that whatever breaks loading/saving is in HLE/modules150/sceUtility.java. I'll try modifing that code to make it work.
EDIT5: I think I have the problem: The savefiles I have are secure files[if (saveFileSecureEntriesAddr != 0) results in true]. Furthermore if(saveFileEntriesAddr != 0) results in a false-value. That alone would be no problem but with the new implementation, there is a if(savedataParams.isSecureFile(entry)) check before checking if we have a value for saveFileSecureEntriesAddr. And that check returns a false.
So I took a closer look to the isSecureFile() function. Said function accesses this value: psf.get("SAVEDATA_FILE_LIST"), which is not set for my savefiles.
What exactly is this SAVEDATA_FILE_LIST and why is it suddenly needed, even though things seem to work without it(at least for my saves)?
EDIT6: I forgot to mention, I had to change mem.write64(entryAddr + 8, ((stat.size + 0xF) & ~0xF) - 0x10); back to mem.write64(entryAddr + 8, stat.size); for things to work. What was that change supposed to do?
So now that I found a way to make saving/loading work for me again, could you explain what SAVEDATA_FILE_LIST and ((stat.size + 0xF) & ~0xF) - 0x10) are supposed to be doing gid15? Any idea why that changes made it impossible to load savegames for VC2[ULUS10515] and VC3[NPJH50343]?
