[Regression] Harry Potter and the Goblet of Fire - ULES00210

[[Unknown]]

Did the save stop working at some point or has it never worked?

-[Unknown]

[GamerzHell9137]

(12-29-2014 04:02 PM)[Unknown] Wrote:  Did the save stop working at some point or has it never worked?

-[Unknown]

Dunno really.

[vnctdj]

Moved to In-game due to the save problem.

[gdmk02]

This one breaks savedata https://github.com/hrydgard/ppsspp/pull/7036

[[Unknown]]

Thanks for checking. That does unfortunately match tests, and I think it actually improved things in a couple games because it reports somewhat more believable numbers.

Are you able to compile it? If so, the easiest way to disable the vast majority of that change is to make a simple change to Core/HW/MemoryStick.cpp.

Find:
u64 MemoryStick_FreeSpace()
{

Add after that:
return 1ULL * 1024 * 1024 * 1024; // 1GB

This will make it always report 1GB free as it did before. If this does fix it, that's really strange. Maybe the game just can't believe 8GB are free on the device? Otherwise, if it does not fix it, maybe I made a mistake in SavedataParam::GetSpaceText(), and it's checking the string version...

Also, if you could try putting PPSSPP on a smaller USB stick or SD card, even without any changes (just current master), that would also be interesting. Basically, PPSSPP reports 8GB free until you have less than 8GB free. So, if you put it on a usb stick that has only < 1GB free, it will report whatever is actually free. This allows the game to tell you when you've run out of space (much more common on phones) rather than silently discarding your saves as it did before.

If < 1GB works, but > 1GB doesn't work, that'll also be interesting, and probably means we're doing something wrong reproducing the values of the PSP.

-[Unknown]

[gdmk02]

return 1ULL * 1024 * 1024 * 1024; // 1GB
the game works correctly.

8.xGB~11.xGB no free space

6.x~7.xGB nonstop print :
54:49:231 idle0 W[SCEGE]: HLE\sceGe.cpp:525 sceGeBreak(mode=0, unknown=08dfeba8): unknown ptr (valid)
54:49:231 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:85 sceUtilitySavedataInitStart(08d89c80) - SIZES (8)
54:49:231 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:86 sceUtilitySavedataInitStart(08d89c80) : Game key (hex):

4.x~5.xGB works good
2.x~3.xGB same as 6.x~7.xGB
0.x~1.xGB works good

[[Unknown]]

Well, that's quite strange.

There are two main places it uses that information. In Core/Dialog/SavedataParam.cpp, it calls that function once right below:

if (param->msFree.IsValid())

And another time right below:

if (param->sizeInfo.IsValid())

If you leave MemoryStick_FreeSpace() at one of the values that doesn't work, and change:

const u64 freeBytes = MemoryStick_FreeSpace();

To:

const u64 freeBytes = 1ULL * 1024 * 1024 * 1024;

Which one makes it work? I'm thinking it will be the sizeInfo one, but not sure at all. Which ever one it is, both have SavedataParam::GetSpaceText(freeBytes) - what if you take out all the changes, and just change one of the SavedataParam::GetSpaceText(freeBytes) to SavedataParam::GetSpaceText(1ULL * 1024 * 1024 * 1024) - does that fix it?

If yes, that could mean it's reading the string and we're formatting it wrong, which is definitely possible. Otherwise, maybe our structs are wrong or incomplete... or that game is somehow specifying a different version / layout.

-[Unknown]

[gdmk02]

the msFree one changed make it works.
change SavedataParam::GetSpaceText(freeBytes) to SavedataParam::GetSpaceText(1ULL * 1024 * 1024 * 1024) won't fix it.

[[Unknown]]

So, I just double checked on my PSP. I have 9079 MB free right now, and it reports:

CHANGE: msFree.clusterSize: 00000000 => 00008000
CHANGE: msFree.freeClusters: 00000000 => 00046efa
CHANGE: msFree.freeSpaceKB: 00000000 => 008ddf40
CHANGE: msFree.freeSpaceStr: => 9079 MB

PPSSPP's only difference is that it reports:

CHANGE: msFree.freeSpaceStr: => 8 GB

Does anything change if you make this modification to GetSpaceText? Find:

std::string SavedataParam::GetSpaceText(u64 size)
{
static const char *suffixes[] = {"B", "KB", "MB", "GB"};
char text[50];

for (size_t i = 0; i < ARRAY_SIZE(suffixes); ++i)
{
if (size < 1024)

And replace that last line with:

if (size < 10240)

This seems to more accurately approximate how the PSP formats it. But, it sounds like this won't help. I wonder if it's something to do with the request.

I think the best thing would be, if you have a PSP, using JpcspTrace. It is a CFW plugin for the PSP that records syscalls so we can compare it with emulators. Here's one set up for savedata:

https://github.com/unknownbrackets/Jpcsp...data-sizes

That will show what the PSP is responding with for this specific savedata SIZES request.

-[Unknown]

[gdmk02]

No,if (size < 10240) won't help.I have a PSP,and what syacalls to log?

[[Unknown]]

I just need to see what's being sent to sceUtilitySavedataInitStart and what gets returned.

For the config, you can use:

sceUtilitySavedataInitStart 0x50C4CD57 1 v
sceUtilitySavedataShutdownStart 0x9790b33c 0

This will log both init and shutdown, and show the request and response.

-[Unknown]

[gdmk02]

Okay, see log attachment.

[[Unknown]]

So, the result makes sense:

clusterSize = 0x00008000
freeClusters = 0x0000E333 (1905885184 bytes)
freeSpaceKB = 0x001C6660 (1905885184 bytes)
freeSpaceText = 1817 MB

And follows roughly with what we're returning. The size of the request is 1500, but that still fits. msFree is the only valid pointer, and it doesn't change or move.

Hmm. Maybe it's something about the timing, but then why would other values work? Does it work in JPCSP?

-[Unknown]

[gdmk02]

jpcsp-r3679-windows-x86-64 is fine.

[Trokinos]

Wanted to mention that from my test
Warriors Orochi 1 (not the 2nd one)
WWE All Stars
are both affected by the same regression mentionned here, in 0.9.9.1 "stable" the game was correctly detecting the PPSSPP "memory stick" and saving to it , but in buildbot versions the games can't save as it does not detect the memory stick having enough space.

The only solution if someone is using buildbot version with those games is to save first with those games loaded into "stable" 0.9.9.1 and move those save back into the buildbot versions , that will allow the game to correctly save then.