[GH-ISSUE #718] missing save screen issue (Suzumiya)

kerem commented

2026-03-17 10:17:57 +03:00

Owner

Originally created by @sum2012 on GitHub (Feb 17, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/718

Game:Suzumiya Haruhi No Tsuisou -ULJS00371
Version:ppsspp-v0.6-504-g9338cf9-windows-x86
(Edit 513 also crash)
JIT crash log: https://gist.github.com/sum2012/4969720
interpreter log:https://gist.github.com/sum2012/4969729

interpreter mode ony can play to attach image.

Originally created by @sum2012 on GitHub (Feb 17, 2013). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/718 Game:Suzumiya Haruhi No Tsuisou -ULJS00371 Version:ppsspp-v0.6-504-g9338cf9-windows-x86 (Edit 513 also crash) JIT crash log: https://gist.github.com/sum2012/4969720 interpreter log:https://gist.github.com/sum2012/4969729 interpreter mode ony can play to attach image. ![1](https://f.cloud.github.com/assets/2177532/164465/deeae362-78a7-11e2-86ef-49dfa3cba492.jpg)

kerem

2026-03-17 10:17:57 +03:00

closed this issue
added the
Saving issue
label

kerem commented

2026-03-17 10:18:14 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Feb 17, 2013):

Have you enabled "Fast memory (dynarec, unstable)"? If yes, it's expected that these lines will crash:

03:17:465 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0000000c PC 088933bc LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 00000008 PC 088933c0 LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0000000c PC 0889340c LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 00000008 PC 08893410 LR 088932e0
03:17:466 MemmapFunctions.cpp:89 W[MM]: ReadFromHardware: Invalid address d0cfba1c PC 088933c8 LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0008ae02 PC 08893410 LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address d0cfba18 PC 08893424 LR 088932e0
03:17:466 MemmapFunctions.cpp:89 W[MM]: ReadFromHardware: Invalid address d0cfba1c PC 088933c8 LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address d0cfba18 PC 08893424 LR 088932e0
03:17:466 MemmapFunctions.cpp:89 W[MM]: ReadFromHardware: Invalid address d0cfba1c PC 088933c8 LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address d0cfba18 PC 08893424 LR 088932e0
03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0000000c PC 0889340c LR 088932e0

On PCs, slowmem shouldn't be that much slower than fastmem, and it should not crash in this case.

-[Unknown]

@unknownbrackets commented on GitHub (Feb 17, 2013): Have you enabled "Fast memory (dynarec, unstable)"? If yes, it's expected that these lines will crash: ``` 03:17:465 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0000000c PC 088933bc LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 00000008 PC 088933c0 LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0000000c PC 0889340c LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 00000008 PC 08893410 LR 088932e0 03:17:466 MemmapFunctions.cpp:89 W[MM]: ReadFromHardware: Invalid address d0cfba1c PC 088933c8 LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0008ae02 PC 08893410 LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address d0cfba18 PC 08893424 LR 088932e0 03:17:466 MemmapFunctions.cpp:89 W[MM]: ReadFromHardware: Invalid address d0cfba1c PC 088933c8 LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address d0cfba18 PC 08893424 LR 088932e0 03:17:466 MemmapFunctions.cpp:89 W[MM]: ReadFromHardware: Invalid address d0cfba1c PC 088933c8 LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address d0cfba18 PC 08893424 LR 088932e0 03:17:466 MemmapFunctions.cpp:121 W[MM]: WriteToHardware: Invalid address 0000000c PC 0889340c LR 088932e0 ``` On PCs, slowmem shouldn't be that much slower than fastmem, and it should not crash in this case. -[Unknown]

kerem commented

2026-03-17 10:18:19 +03:00

Author

Owner

@sum2012 commented on GitHub (Feb 17, 2013):

It is default option.
Turn off fix crash.
Now close the issue ?
(Also need make pull request in disable Fast memory in default ?)

@sum2012 commented on GitHub (Feb 17, 2013): It is default option. Turn off fix crash. Now close the issue ? (Also need make pull request in disable Fast memory in default ?)

kerem commented

2026-03-17 10:18:24 +03:00

Author

Owner

@hrydgard commented on GitHub (Feb 17, 2013):

Well, there's still some bug somewhere - the game should not try to write/read invalid addresses, so something has gone wrong earlier.

@hrydgard commented on GitHub (Feb 17, 2013): Well, there's still some bug somewhere - the game should not try to write/read invalid addresses, so something has gone wrong earlier.

kerem commented

2026-03-17 10:18:29 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Feb 17, 2013):

Most probably with the font or psmf stuff. But it's not a jit bug is what I meant.

-[Unknown]

@unknownbrackets commented on GitHub (Feb 17, 2013): Most probably with the font or psmf stuff. But it's not a jit bug is what I meant. -[Unknown]

kerem commented

2026-03-17 10:18:35 +03:00

Author

Owner

@sum2012 commented on GitHub (Feb 17, 2013):

@unknownbrackets
I have changed to write/read invalid addresses issue

@sum2012 commented on GitHub (Feb 17, 2013): @unknownbrackets I have changed to write/read invalid addresses issue

kerem commented

2026-03-17 10:18:40 +03:00

Author

Owner

@sum2012 commented on GitHub (Mar 2, 2013):

v0.6-843 can play futher but random crash
https://gist.github.com/sum2012/0bded2c58b994eac096f

@sum2012 commented on GitHub (Mar 2, 2013): v0.6-843 can play futher but random crash https://gist.github.com/sum2012/0bded2c58b994eac096f ![1](https://f.cloud.github.com/assets/2177532/213084/94b3e83a-8355-11e2-81ba-95534c7b2994.jpg)

kerem commented

2026-03-17 10:18:45 +03:00

Author

Owner

@sum2012 commented on GitHub (Mar 4, 2013):

Sometime another error:black screen after
https://f.cloud.github.com/assets/2177532/213084/94b3e83a-8355-11e2-81ba-95534c7b2994.jpg
log:
https://gist.github.com/sum2012/5c8bcfbc69cdd3fd1144

@sum2012 commented on GitHub (Mar 4, 2013): Sometime another error:black screen after https://f.cloud.github.com/assets/2177532/213084/94b3e83a-8355-11e2-81ba-95534c7b2994.jpg log: https://gist.github.com/sum2012/5c8bcfbc69cdd3fd1144

kerem commented

2026-03-17 10:18:50 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 9, 2013):

Is this game working any better now?

-[Unknown]

@unknownbrackets commented on GitHub (Jun 9, 2013): Is this game working any better now? -[Unknown]

kerem commented

2026-03-17 10:18:55 +03:00

Author

Owner

@sum2012 commented on GitHub (Jun 9, 2013):

ppsspp-v0.7.6-1245
same black screen after save screen.
https://gist.github.com/sum2012/2c8626869962d070a895
Will make VS 2010 debug log when I have time

Some interest
42:16:212 Test Thread I[HLE]: HLE\sceIo.cpp:541 stderr:
C++ runtime abort: internal error: static object marked for destruction more than once
42:16:212 Test Thread E[HLE]: HLE\sceKernelModule.cpp:1256 UNIMPL sceKernelStopUnloadSelfModuleWithStatus(00000001, 00000000, 00000000, 00000000, 00000000): game has likely crashed
42:16:212 Test Thread E[HLE]: HLE\sceKernelMemory.cpp:644 UNIMPL sceKernelPrintf(libc:%s: something wrong 0x%08X, 08ac49e0, 00000000, 00000000)
42:16:212 Test Thread E[CPU]: Mips\MIPSInt.cpp:195 BREAK!

@sum2012 commented on GitHub (Jun 9, 2013): ppsspp-v0.7.6-1245 same black screen after save screen. https://gist.github.com/sum2012/2c8626869962d070a895 Will make VS 2010 debug log when I have time Some interest 42:16:212 Test Thread I[HLE]: HLE\sceIo.cpp:541 stderr: C++ runtime abort: internal error: static object marked for destruction more than once 42:16:212 Test Thread E[HLE]: HLE\sceKernelModule.cpp:1256 UNIMPL sceKernelStopUnloadSelfModuleWithStatus(00000001, 00000000, 00000000, 00000000, 00000000): game has likely crashed 42:16:212 Test Thread E[HLE]: HLE\sceKernelMemory.cpp:644 UNIMPL sceKernelPrintf(libc:%s: something wrong 0x%08X, 08ac49e0, 00000000, 00000000) 42:16:212 Test Thread E[CPU]: Mips\MIPSInt.cpp:195 BREAK!

kerem commented

2026-03-17 10:19:00 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 9, 2013):

That is very interesting. Looks possibly sceFont related...

-[Unknown]

@unknownbrackets commented on GitHub (Jun 9, 2013): That is very interesting. Looks possibly sceFont related... -[Unknown]

kerem commented

2026-03-17 10:19:05 +03:00

Author

Owner

@sum2012 commented on GitHub (Jun 10, 2013):

@unknownbrackets
Can you correctly update sceKernelPrintf from this
http://forums.ppsspp.org/showthread.php?tid=3125
to me to test.Thanks.

@sum2012 commented on GitHub (Jun 10, 2013): @unknownbrackets Can you correctly update sceKernelPrintf from this http://forums.ppsspp.org/showthread.php?tid=3125 to me to test.Thanks.

kerem commented

2026-03-17 10:19:10 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 10, 2013):

That version of sceKernelPrintf() is unfortunately not correct. Just need to whitelist 'X' really...

But it's basically saying it got a 0 when not expecting it.

-[Unknown]

@unknownbrackets commented on GitHub (Jun 10, 2013): That version of sceKernelPrintf() is unfortunately not correct. Just need to whitelist 'X' really... But it's basically saying it got a 0 when not expecting it. -[Unknown]

kerem commented

2026-03-17 10:19:15 +03:00

Author

Owner

@sum2012 commented on GitHub (Jun 11, 2013):

JPCSP also have this probrem in new version.
It is about sceUtilityOsk change.Will keep you update when it fixed

@sum2012 commented on GitHub (Jun 11, 2013): JPCSP also have this probrem in new version. It is about sceUtilityOsk change.Will keep you update when it fixed

kerem commented

2026-03-17 10:19:20 +03:00

Author

Owner

@sum2012 commented on GitHub (Jun 12, 2013):

@unknownbrackets JPCSP fix this probrem in
http://code.google.com/p/jpcsp/source/detail?r=3230
Do PPSSPP need do the same ?

@sum2012 commented on GitHub (Jun 12, 2013): @unknownbrackets JPCSP fix this probrem in http://code.google.com/p/jpcsp/source/detail?r=3230 Do PPSSPP need do the same ?

kerem commented

2026-03-17 10:19:25 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 13, 2013):

I'm not sure it's the same problem then, because that mostly seems to make JPCSP use logic more similar to PPSSPP's current logic (although I'm not sure.)

It does seem to ignore negative values, though, you can try this:

Core/Dialog/PSPOskDialog.cpp:

u32 PSPOskDialog::FieldMaxLength()
{
    if (oskParams->fields[0].outtextlimit > oskParams->fields[0].outtextlength - 1 || oskParams->fields[0].outtextlimit <= 0)
        return oskParams->fields[0].outtextlength - 1;
    return oskParams->fields[0].outtextlimit;
}

-[Unknown]

@unknownbrackets commented on GitHub (Jun 13, 2013): I'm not sure it's the same problem then, because that mostly seems to make JPCSP use logic more similar to PPSSPP's current logic (although I'm not sure.) It does seem to ignore negative values, though, you can try this: Core/Dialog/PSPOskDialog.cpp: ``` u32 PSPOskDialog::FieldMaxLength() { if (oskParams->fields[0].outtextlimit > oskParams->fields[0].outtextlength - 1 || oskParams->fields[0].outtextlimit <= 0) return oskParams->fields[0].outtextlength - 1; return oskParams->fields[0].outtextlimit; } ``` -[Unknown]

kerem commented

2026-03-17 10:19:30 +03:00

Author

Owner

@sum2012 commented on GitHub (Jun 13, 2013):

No help

@sum2012 commented on GitHub (Jun 13, 2013): No help

kerem commented

2026-03-17 10:19:35 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

How does this look now? Still the same?

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): How does this look now? Still the same? -[Unknown]

kerem commented

2026-03-17 10:19:41 +03:00

Author

Owner

@sum2012 commented on GitHub (Sep 2, 2013):

same.Can I use JPCSP trace log (with some modules) to solve ?

@sum2012 commented on GitHub (Sep 2, 2013): same.Can I use JPCSP trace log (with some modules) to solve ?

kerem commented

2026-03-17 10:19:46 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 2, 2013):

Hmm. It might help, but I'm not sure which functions to hook. Maybe sceSasSetVoicePCM... but not really sure.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 2, 2013): Hmm. It might help, but I'm not sure which functions to hook. Maybe sceSasSetVoicePCM... but not really sure. -[Unknown]

kerem commented

2026-03-17 10:19:51 +03:00

Author

Owner

@sum2012 commented on GitHub (Sep 10, 2013):

@unknownbrackets I should give you see newest debug log first.
https://docs.google.com/file/d/0B3OaSdeV0L8kbVhtRWNZNm1jY3M/edit?usp=sharing
still sceSasSetVoicePCM ?

@sum2012 commented on GitHub (Sep 10, 2013): @unknownbrackets I should give you see newest debug log first. https://docs.google.com/file/d/0B3OaSdeV0L8kbVhtRWNZNm1jY3M/edit?usp=sharing still sceSasSetVoicePCM ?

kerem commented

2026-03-17 10:19:56 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 11, 2013):

Well, the game says this:

C++ runtime abort: internal error: static object marked for destruction more than once

That's bad. It's within the OSK and PPGe stuff, so likely to be related. It's probably something to do with sceGe, but that will be a lot to log...

It could even just be because the OSK proceeds through the statuses too quickly.

Does it happen if you comment out these lines in Core/Util/PPGeDraw.cpp?

    if (dataWritePtr > dataPtr) {
        sceGeBreak(0);
        sceGeSaveContext(savedContextPtr);
        gpu->EnableInterrupts(false);

        // We actually drew something
        u32 list = sceGeListEnQueueHead(dlPtr, dlWritePtr, -1, 0);
        DEBUG_LOG(SCEGE, "PPGe enqueued display list %i", list);
        gpu->EnableInterrupts(true);
        sceGeContinue();
        sceGeRestoreContext(savedContextPtr);
    }

-[Unknown]

@unknownbrackets commented on GitHub (Sep 11, 2013): Well, the game says this: ``` C++ runtime abort: internal error: static object marked for destruction more than once ``` That's bad. It's within the OSK and PPGe stuff, so likely to be related. It's probably something to do with sceGe, but that will be a lot to log... It could even just be because the OSK proceeds through the statuses too quickly. Does it happen if you comment out these lines in Core/Util/PPGeDraw.cpp? ``` c++ if (dataWritePtr > dataPtr) { sceGeBreak(0); sceGeSaveContext(savedContextPtr); gpu->EnableInterrupts(false); // We actually drew something u32 list = sceGeListEnQueueHead(dlPtr, dlWritePtr, -1, 0); DEBUG_LOG(SCEGE, "PPGe enqueued display list %i", list); gpu->EnableInterrupts(true); sceGeContinue(); sceGeRestoreContext(savedContextPtr); } ``` -[Unknown]

kerem commented

2026-03-17 10:20:01 +03:00

Author

Owner

@sum2012 commented on GitHub (Sep 11, 2013):

No help
https://docs.google.com/file/d/0B3OaSdeV0L8kLVVDMXMzMVVYVmc/edit?usp=sharing

@sum2012 commented on GitHub (Sep 11, 2013): No help https://docs.google.com/file/d/0B3OaSdeV0L8kLVVDMXMzMVVYVmc/edit?usp=sharing

kerem commented

2026-03-17 10:20:06 +03:00

Author

Owner

@sum2012 commented on GitHub (Sep 11, 2013):

Maybe we should review which commit break OSK.
Fast test
good
ppsspp-v0.7.5-276-gb200005
bad
ppsspp-v0.7.5-318-g570ddb2

@sum2012 commented on GitHub (Sep 11, 2013): Maybe we should review which commit break OSK. Fast test good ppsspp-v0.7.5-276-gb200005 bad ppsspp-v0.7.5-318-g570ddb2

kerem commented

2026-03-17 10:20:11 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 11, 2013):

Before those commits we were overwriting memory and corrupting the game's stack. Maybe there's still an issue, but it was definitely more incorrect before those changes.

-[Unknown]

@unknownbrackets commented on GitHub (Sep 11, 2013): Before those commits we were overwriting memory and corrupting the game's stack. Maybe there's still an issue, but it was definitely more incorrect before those changes. -[Unknown]

kerem commented

2026-03-17 10:20:16 +03:00

Author

Owner

@sum2012 commented on GitHub (Sep 11, 2013):

git bisect result

edit: this commit ?
github.com/hrydgard/ppsspp@27cf72afb6

PPSSPP v0.7.5-280-g7baf27b First OSK break
https://docs.google.com/file/d/0B3OaSdeV0L8kaC1JX2p5V0hQZHc/edit?usp=sharing

PPSSPP v0.7.5-277-gf8d726c Last OSK good
https://docs.google.com/file/d/0B3OaSdeV0L8kZ01GbWVlRFlNQ2M/edit?usp=sharing

@sum2012 commented on GitHub (Sep 11, 2013): git bisect result ![1](https://f.cloud.github.com/assets/2177532/1123647/bc232860-1af2-11e3-88b5-a87a6961c020.png) edit: this commit ? https://github.com/hrydgard/ppsspp/commit/27cf72afb6b92a9253a43385c785e64c3b9ae104 PPSSPP v0.7.5-280-g7baf27b First OSK break https://docs.google.com/file/d/0B3OaSdeV0L8kaC1JX2p5V0hQZHc/edit?usp=sharing PPSSPP v0.7.5-277-gf8d726c Last OSK good https://docs.google.com/file/d/0B3OaSdeV0L8kZ01GbWVlRFlNQ2M/edit?usp=sharing

kerem commented

2026-03-17 10:20:21 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 11, 2013):

Well, the field length is correct, but I found one thing. Does #3732 fix it?

-[Unknown]

@unknownbrackets commented on GitHub (Sep 11, 2013): Well, the field length is correct, but I found one thing. Does #3732 fix it? -[Unknown]

kerem commented

2026-03-17 10:20:26 +03:00

Author

Owner

@sum2012 commented on GitHub (Sep 11, 2013):

Well done,finally fix it
:)

@sum2012 commented on GitHub (Sep 11, 2013): Well done,finally fix it :)

kerem commented

2026-03-17 10:20:31 +03:00

Author

Owner

@sum2012 commented on GitHub (Sep 11, 2013):

Post a good picture to prove

@sum2012 commented on GitHub (Sep 11, 2013): Post a good picture to prove ![1](https://f.cloud.github.com/assets/2177532/1124026/0b0f070a-1af8-11e3-9b0a-d4f263a5a6c5.jpg)

kerem commented

2026-03-17 10:20:36 +03:00

Author

Owner

@hrydgard commented on GitHub (Sep 11, 2013):

OK, I close it then :) (I merged the fix)

@hrydgard commented on GitHub (Sep 11, 2013): OK, I close it then :) (I merged the fix)

kerem commented

2026-03-17 10:20:41 +03:00

Author

Owner

@sum2012 commented on GitHub (Oct 23, 2013):

Oh no ,the game still invalid addresses
last time I only lucky no probrem.
Firstly I give back PPSSPP v0.9.1-762-gbd8a4ec log (OSK fixed version)

After OSK, invalid addresses
case 1:https://gist.github.com/sum2012/67b36e6bb11a93b289b3
case 2:https://gist.github.com/sum2012/51299f817b3be3edba98
Good log:https://gist.github.com/sum2012/7bcd52366290f0a6e381

should re-open the issue

@sum2012 commented on GitHub (Oct 23, 2013): Oh no ,the game still invalid addresses last time I only lucky no probrem. Firstly I give back PPSSPP v0.9.1-762-gbd8a4ec log (OSK fixed version) After OSK, invalid addresses case 1:https://gist.github.com/sum2012/67b36e6bb11a93b289b3 case 2:https://gist.github.com/sum2012/51299f817b3be3edba98 Good log:https://gist.github.com/sum2012/7bcd52366290f0a6e381 should re-open the issue

kerem commented

2026-03-17 10:20:47 +03:00

Author

Owner

@sum2012 commented on GitHub (Oct 23, 2013):

PPSSPP v0.9.1-2105-gb0d7f75 log:
bad1:https://gist.github.com/sum2012/fb84e85e0361ec701bec
bad2:https://gist.github.com/sum2012/3cd7779b4dad802b68e4
good:https://gist.github.com/sum2012/f2ff6f4f7d6823c279a5

debug (stop at first error):https://docs.google.com/file/d/0B3OaSdeV0L8kYU91YUMxOV9vLTA/edit?usp=sharing

@sum2012 commented on GitHub (Oct 23, 2013): PPSSPP v0.9.1-2105-gb0d7f75 log: bad1:https://gist.github.com/sum2012/fb84e85e0361ec701bec bad2:https://gist.github.com/sum2012/3cd7779b4dad802b68e4 good:https://gist.github.com/sum2012/f2ff6f4f7d6823c279a5 debug (stop at first error):https://docs.google.com/file/d/0B3OaSdeV0L8kYU91YUMxOV9vLTA/edit?usp=sharing

kerem commented

2026-03-17 10:20:52 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Oct 23, 2013):

So it's random? Is it affected by multithreading or buffered rendering settings?

-[Unknown]

@unknownbrackets commented on GitHub (Oct 23, 2013): So it's random? Is it affected by multithreading or buffered rendering settings? -[Unknown]

kerem commented

2026-03-17 10:20:57 +03:00

Author

Owner

@sum2012 commented on GitHub (Oct 23, 2013):

Yes it is random,don't affected by multithreading , buffered rendering or JIT settings.

@sum2012 commented on GitHub (Oct 23, 2013): Yes it is random,don't affected by multithreading , buffered rendering or JIT settings.

kerem commented

2026-03-17 10:21:02 +03:00

Author

Owner

@sum2012 commented on GitHub (Oct 27, 2013):

Check with real PSP.It is missing this screen when no save.

Click Circle then psp create data.
If PPSSPP use Real psp save ,ppsspp would not have probrem (tested 4 times)
JPCSP trace log (before OSK)
https://gist.github.com/sum2012/d0641205e8a5fefad647
Real PSP save (before OSK)
https://drive.google.com/file/d/0B3OaSdeV0L8kV2ZJQlhKd3lsWUE/edit?usp=sharing
Edit:PPSSPP do not create save before OSK

@sum2012 commented on GitHub (Oct 27, 2013): Check with real PSP.It is missing this screen when no save. ![sl380944](https://f.cloud.github.com/assets/2177532/1415452/cfac1e56-3f04-11e3-99fc-3c714bdd5144.JPG) Click Circle then psp create data. If PPSSPP use Real psp save ,ppsspp would not have probrem (tested 4 times) JPCSP trace log (before OSK) https://gist.github.com/sum2012/d0641205e8a5fefad647 Real PSP save (before OSK) https://drive.google.com/file/d/0B3OaSdeV0L8kV2ZJQlhKd3lsWUE/edit?usp=sharing Edit:PPSSPP do not create save before OSK

kerem commented

2026-03-17 10:21:07 +03:00

Author

Owner

@sum2012 commented on GitHub (Oct 27, 2013):

PPSSPP log (no save, before OSK)
Info log
https://gist.github.com/sum2012/c72d9900a34bcbfee046
Debug log (no save ,before OSK)
https://drive.google.com/file/d/0B3OaSdeV0L8kdFRlQnc2WXBUeFE/edit?usp=sharing

tag @shenweip whether he has idea to fix

@sum2012 commented on GitHub (Oct 27, 2013): PPSSPP log (no save, before OSK) Info log https://gist.github.com/sum2012/c72d9900a34bcbfee046 Debug log (no save ,before OSK) https://drive.google.com/file/d/0B3OaSdeV0L8kdFRlQnc2WXBUeFE/edit?usp=sharing tag @shenweip whether he has idea to fix

kerem commented

2026-03-17 10:21:12 +03:00

Author

Owner

@sum2012 commented on GitHub (Oct 27, 2013):

Add sceUtilitySavedataGetStatus in JPCSP trace log
https://gist.github.com/sum2012/30cf7a85403b8406959f

@sum2012 commented on GitHub (Oct 27, 2013): Add sceUtilitySavedataGetStatus in JPCSP trace log https://gist.github.com/sum2012/30cf7a85403b8406959f

kerem commented

2026-03-17 10:21:17 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jan 30, 2014):

Just in case: does it work any better with softgpu?

-[Unknown]

@unknownbrackets commented on GitHub (Jan 30, 2014): Just in case: does it work any better with softgpu? -[Unknown]

kerem commented

2026-03-17 10:21:22 +03:00

Author

Owner

@sum2012 commented on GitHub (Jan 30, 2014):

No help

@sum2012 commented on GitHub (Jan 30, 2014): No help

kerem commented

2026-03-17 10:21:27 +03:00

Author

Owner

@sum2012 commented on GitHub (Feb 8, 2014):

Well done
PPSSPP v0.9.6-802 The save screen apeear

Log:https://gist.github.com/sum2012/4763b79579b8d07c5ed8
The game should no problem.

@sum2012 commented on GitHub (Feb 8, 2014): Well done PPSSPP v0.9.6-802 The save screen apeear ![1](https://f.cloud.github.com/assets/2177532/2118704/ac9ce8ac-9119-11e3-9055-4ab30e0bba8e.jpg) Log:https://gist.github.com/sum2012/4763b79579b8d07c5ed8 The game should no problem.

kerem commented

2026-03-17 10:21:32 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Feb 8, 2014):

Awesome. That makes it seem likely that #5360 will be improved as well.

-[Unknown]

@unknownbrackets commented on GitHub (Feb 8, 2014): Awesome. That makes it seem likely that #5360 will be improved as well. -[Unknown]

Rows
Columns

[GH-ISSUE #718] missing save screen issue (Suzumiya) #207