sp193
Developer
I backported the changes, but could not get it to work with decent performance, without adjusting SMSTCPIP. The current parameters seemed to somehow allow OPL to work around the Windows TCP congestion control algorithm.
Well, at least I think it is because my PC will wait for a TCP window update by the PS2, whenever the receive window reaches 2200/5120.
Once I set the TCP receive window to 16384 and gave it 16 PBUFs, I could watch the Valkyrie Profile 2 OP without any pauses.
Unfortunately, there is an interest in using as little memory as possible and increasing just the TCP window doesn't work. Likely because the frames come really quickly, and then they get dropped when no PBUFs are available.
I also applied the OPL workaround for the Windows TCP congestion algorithm by receiving operations to 8192 bytes, while keeping the TCP receive window ahead at 10240 bytes. I guess, it's still an improvement? lol
Writing is still "unlimited" at 65535 bytes per chunk.
To make up for this slight increase in memory usage, I also removed the functions that OPL does not require.
I realized that I don't understand the relationship between CDVDFSV_BUF_SECTORS and CDVDMAN_FS_SECTORS. I've forgotten what it was about, what the +2 was for.
Since I could not find an explanation for it, I consolidated these 2 into one definition. Some testing should be done because I really don't know why I had this +2 sectors in the first place. I guess, it was for an earlier design of OPL or there was a mistake in CDVDFSV.
Test build: https://www.sendspace.com/file/wimba1
Branch: https://github.com/sp193/Open-PS2-Loader/tree/smb-update
Even with the latest commit I still have games missing. I don't have many games on my share since I usually use HDD, but the once I have that are missing are modified/translated games. However they work on prior revisions and on USB, so it shouldn't be the games.
EDIT: It seems to occur when there are more than one entry with the same GAME ID.
Unfortunately, I seem to have misinterpreted the meaning of the filename length field. It's in bytes, not characters.
Somehow it worked, but wasn't working properly. It should be fine now.
There's also this glitch within OPL's ISOFS module, causing mounting to always fail once it has failed once. It's because the file descriptor is never marked as available again, once if mounting failed once.
If you're able to get an increase of speed by sacrificing a bit of memory, couldn't it become a MODE? Or is the new code with larger buffers still not faster than current code?
Most of these network stack options are not configurable during runtime. So I would need to duplicate SMSTCPIP and CDVDMAN again, which will increase the code size by another 200KB or something.
I'm trying to not increase the number of compatibility modes because entertainment should be hassle-free and fun.
Whether it's faster or not... I don't really know. Logic dictates that it should be better. But the IOP is too restrictive and we're trying to save memory, a bit too hard. I'm hoping that it'll actually work out this time.
I was playing some Ps1 games with the last Ps2-Home DB… I was playing it from USB (POPS games too are on USB HDD), when I IGR from POPS it starts OPL ifcaro build ('cause I've it in BOOT folder, named as BOOT.ELF) and it couldn't load my iHDD game-list.
After a couple seconds, it loop on the loading icon, exactly as it used to do when IGResetting from some Ps2 games (like Ace Combat).
I wonder if listing POPS games as APPS, then IGResetting it would happen the same problem.
Do you have USB mode set to AUTO? If yes, then it is possible that your USB device has become unresponsive.
PS2 apps have full control over the PS2, so this may be a POPS problem. This may happen if transfers are interrupted.