Add Simulate UMD slow reading speed in UI

[sum2012]

Fix #11062 fix #12512 fix #9993
A small note 400000 fail

[anr2me]

Could there be another issue if it need such a long delay just to open the file?

[sum2012]

There is the theory that Real PSP can in-game in CSO format rather than ISO format, decompression using real PSP's CPU should be much slower.
The UMD might have copyright protection scheme so that it read data really slow.
This is only game that need this slow speed so that I don't interest to find another solution
JPCSPTrace of Aces of War (Europe) of CSO format
https://gist.github.com/sum2012/233b04ae988303655b103aa6f95c1fd0
(The hanging of PPSSPP of reading of the file timing )
20:11:21.106496 Load Thread - -> sceIoOpen 0x09F9ABB0('disc0:/PSP_GAME/USRDIR/UMAP/000.BIN'), 0x1, 0x0 = 0x0
20:11:21.113254 Load Thread - <- sceIoOpen 0x09F9ABB0('disc0:/PSP_GAME/USRDIR/UMAP/000.BIN'), 0x1, 0x0 = 0x4

edit: So the timing ~0.07 s = 70ms , much more than unknownbrackets measure

[sum2012]

I also give a fix for jpcsp emulator
jpcsp/jpcsp#510

[IrfanH495]

I hope this can help sengoku musou 3z to choose dlc costumes

[sum2012]

@IrfanH495 You can download this build of windows 64 bit in
https://github.com/hrydgard/ppsspp/actions/runs/6574857743#artifacts
You need add the game in compat.ini in UMDReadSpeed section

[IrfanH495]

@sum2012 thank you, but unfortunately I don't have a PC/laptop to run it.

[sum2012]

@IrfanH495
I am telling my friend to send the DLC to me (I have the game but not DLC )
In the while , I am trying to make it to menu (Under Simulate UMD Delay)

[sum2012]

@IrfanH495 confirm fixed the DLC
I do not play much so that I cannot test #12512
Do you have a save so that I can test #12512 ? (Upload in here in zip )

[IrfanH495]

@sum2012 Not long ago my save data was deleted, in this save state I created 9 characters, I think it's the same as the DLC costume
PPSSPP_STATE.zip

[sum2012]

@IrfanH495 unlucky not solve

[IrfanH495]

@sum2012 For #12512 ForceUMDDelay for me it's enough but for DLC costumes it still freezes

7_720p.mp4

[sum2012]

I will try to increase reading speed to other sceio function

[sum2012]

I force it also make delay as ForceUMDDelay .
So it also fix #12512

[anr2me]

edit: So the timing ~0.07 s = 70ms , much more than unknownbrackets measure

400 or 500ms is still far off from 70ms, although access time could get worse due to scratches or damages on the disc, and gets faster due to cache.
May be the delay should be spread out to other sceIo syscalls (ie. sceIoRead) instead of lumping it on sceIoOpen?

PS: If i'm not mistaken, Aces of War read the whole file on a single sceIoRead, so the delay may need to be adjusted based on the size it read too, but not sure whether the sector location of the file need to be considered too or not tho (probably only affects seek time).
As i remembered this game, do sceIoOpen followed by sceIoLSeek x3 (with all offset set to 0, the first seek seems to be from the end, probably to get the file size, and then seek from the start x2, not sure why it did the same seek twice tho), followed by sceIoRead, and then sceIoClose, so seeking x3 probably took some time too.

[sum2012]

Update Jpcsptrace log:
https://gist.github.com/sum2012/4d161b95c65e0a4d7c95ce5024f6321a

00:04:03.139435 Load Thread - -> sceIoOpen 0x09F9ABB0('disc0:/PSP_GAME/USRDIR/UMAP/001.BIN'), 0x1, 0x0 = 0x0
00:04:03.145797 Load Thread - <- sceIoOpen 0x09F9ABB0('disc0:/PSP_GAME/USRDIR/UMAP/001.BIN'), 0x1, 0x0 = 0x4
~ 0.006s = 60 ms
00:04:03.146031 Load Thread - -> sceIoLseek 0x4, 0xDEADBEEF, 0x0 = 0x0
00:04:03.146103 Load Thread - <- sceIoLseek 0x4, 0xDEADBEEF, 0x0 = 0x416180

00:04:03.194278 Load Thread - -> sceIoLseek 0x4, 0xDEADBEEF, 0x0 = 0x0
00:04:03.194369 Load Thread - <- sceIoLseek 0x4, 0xDEADBEEF, 0x0 = 0x0

00:04:03.194424 Load Thread - -> sceIoLseek 0x4, 0xDEADBEEF, 0x0 = 0x0
00:04:03.194481 Load Thread - <- sceIoLseek 0x4, 0xDEADBEEF, 0x0 = 0x0

too low value of compare sceIoLseek so that can ignore

00:04:03.194540 Load Thread - -> sceIoRead 0x4, 0x960B980, 0x416180 = 0x0
00:04:09.705600 Load Thread - <- sceIoRead 0x4, 0x960B980, 0x416180 = 0x416180

~6.5 s = 6500 ms

[unknownbrackets]

edit: So the timing ~0.07 s = 70ms , much more than unknownbrackets measure

There's a few things here, but the measurements in PPSSPP are based on a high speed memory stick, and speeds of the memory stick could vary a lot (they had different price points.) It's also true that many CFW had slow CSO decompression (in part because they usually re-read the index data and would often read block by block, slowly. The timings in PPSSPP are just based on memory stick read timings, not based on any of these CFW drivers.

But there's another problem: you're simply measuring when the thread calls sceIoOpen() to when the sceIoOpen() call finishes. While that may sound right, other threads are running on the device. If it starts processing some audio data or does some other processing on another better-priority thread, you could easily see a sceIoOpen() call take milliseconds or even seconds to "finish". It's necessary to look at the overall context of what's happening at the same time. That said, it can be more useful looking at averages. Often these won't have anything else happening.

Also, I found, at least on the PSP-3000 and with actual UMDs, that there was clearly some kind of path cache. Opening files was pretty fast, but only after reading from it once. It could even be that this cache is stored in volatile memory and is lost when volatile memory is locked (but probably not, just saying that I don't know the specific rules around it.) I don't think this cache is in the PSP-2000+ cache RAM, though, because I saw this even running homebrew code that had the UMD cache RAM disabled.

IOTIMING_REALISTIC is probably a bad name. I've said this before, but it is simply unrealistically fast timings for UMD (well, I have seen some evidence that maybe the UMD cache is even faster actually, but not sure of that) + some seek delay timings.

If you are able to play multiple PSP games without the game sometimes hanging when a new sound effect or graphical effect has to show, you can be pretty sure you're not getting realistic timing. That was a common event on a real PSP: you'd cast a spell you hadn't used this play session, and suddenly the music would hang and all you could hear was the UMD drive spinning up (okay, I'm exaggerating slightly - most games were able to keep the music playing.) This might take 2-3 seconds at least. It obviously didn't happen in every game, but it did in many. If you don't experience that in PPSSPP, you can be sure the timings are very very unrealistic.

-[Unknown]

[sum2012]

@unknownbrackets I have changed the timing on __IoRead ,do you agree ?
IOTIMING_REALISTIC ,I do not have idea to rename

[hrydgard]

I think something like this is OK to have as an option and compat setting, and the simplified version in your newest commits should be fine, that just adjusts the throughput of the reads.

The name "UMD slow read speed" gets the point across I guess.. I'll see if I can come up with something better until tomorrow, then we'll get this in.

[leoxxx]

Simulate UMD delays = 模拟 UMD 延迟
@sum2012 @hrydgard
Sengoku Musou 3 Z Special is O.K. Great! But,where is the option?

[hrydgard]

@leoxxx System: IO Timing Method -> Simulate UMD slow reading speed"

[leoxxx]

@hrydgard
THX. I play the game with old verison setting is also O.K. The option default is: Fast (lag on slow storage) = 快速模式(存储低速时有延迟). Dose it auto set for game?

[hrydgard]

Yes, we force it on for some games using compat.ini.