PS2 [Open PS2 Loader] Game Bug Reports

Grahf said:
The only difference with USB would be the reading speed, right? If it works from USB, then the only logical reason for that is slower reading speed.
Click to expand...
This is a complicated thing IMO. Depending on the bug, speed alone might not be the problem - but rather, how the threads are allowed to switch (and hence violate critical sections).

An example would be the case of the Disaster Report game. It would only occur if the user was to use a HDD unit, but cannot be made to go away, regardless of how slow you make data transfers. I did try making it ridiculously slow with longer delays, but it did nothing.
In fact, the bug wasn't related to data transfers at all, but the sound driver was breaking a rule that went along the lines of saying that the the atick function of modmidi and modhsyn should be called, if sound data is removed or added.

The same sound driver module also seemed to have an issue with correctly protecting its critical sections, likely due to the assumption by the developers that the atick thread will always run when the RPC thread does not, not holding.

By right, nobody is supposed to perform timing based on the transfer rate of the CD/DVD drive. So I would deem all these faulty behaviour to be due to game bugs. Unless somebody finds something wrong with OPL itself, but then such a thing would probably have affected all types of devices.
 
sp193 said:
By right, nobody is supposed to perform timing based on the transfer rate of the CD/DVD drive. So I would deem all these faulty behaviour to be due to game bugs.
Click to expand...
Game developers often used very weird code on consoles. It only mattered to them if the game worked on a stock system, so now we might have buggy games which nonetheless should be like that to keep full compatibility. Since OPL is a game loader, it should only seek maximum compatibility, but that indeed might entail ensuring support for buggy games. It was similar with PS1. Did you know that Naughty Dogs did something very strange with the SPU registers in Crash Team Racing, even though it wasn't documented by Sony in any way? Now PSIO can't fully support that game because it's something which no PSIO dev even thought about until they saw it in CTR.

sp193 said:
This is a complicated thing IMO. Depending on the bug, speed alone might not be the problem - but rather, how the threads are allowed to switch (and hence violate critical sections).
Click to expand...
In theory, yes, but since this is the only game that seems to exhibit such behaviour and since HDD is much more compatible by definition, doesn't it seem far-fetched to assume it's anything other than speed?

EDIT: jolek provided me the game for testing and I can say that it goes crazy with anything other than Mode 1. It sometimes doesn't even load the first level if Mode 1 isn't enabled. However, the textures are indeed missing. IMHO, HDD is too fast for this game even with Mode 1. Since it's a CD game, perhaps the developers adjusted it for the very slow CD reading speed and that's why it only works via USB, the slowest possible solution in OPL?

EDIT: Seems the only other PS2 game which works only through USB is this: http://www.psx-place.com/threads/open-ps2-loader-game-bug-reports.19401/page-3#post-144669

Notice how it's also a CD game. This can't be a coincidence. It seems HDD is too fast even with Mode 1 for these CD-optimized games.
 
Last edited:
Grahf said:
EDIT: Seems the only other PS2 game which works only through USB is this: http://www.psx-place.com/threads/open-ps2-loader-game-bug-reports.19401/page-3#post-144669

Notice how it's also a CD game. This can't be a coincidence. It seems HDD is too fast even with Mode 1 for these CD-optimized games.
Click to expand...
Before r679 this game didn't work on USB either and SMB changed it's behaviour with the same commit. Also earlier revs. were even worse than HDD is now, SMB is still worse than HDD.
 
PS2 uses two drives in one. It has a 24x speed CD-ROM (3.6 MB/s) and a 4x speed DVD-ROM (5.28 MB/s). Mode 1 and/or MDMA-0 are great at emulating the DVD-ROM reading speed. However, they are still much faster than the CD-ROM reading speed. I'm sure this is why these two CD games don't work from HDD, but do work from USB. The current speed via USB is very close to the CD-ROM reading speed.

There's no point in looking into those ancient commits. Old OPL had terrible performance issues (like with Onimusha 2). At some point, the performance might have been so bad that these games actually loaded because of it, but there's no point in going back to that. What we need is a compatibility mode for CD games.
 
Last edited:
sp193, would you be able to make a test branch on github with something like mode 7 limiting read speed to CD levels? Just to test the theory.
Or at least point at the code that would change the mode 1 speed.
 
Zarper said:
sp193, would you be able to make a test branch on github with something like mode 7 limiting read speed to CD levels? Just to test the theory.
Or at least point at the code that would change the mode 1 speed.
Click to expand...
I don't think we should touch Mode 1 as it would most likely break DVD games. However, adding a new mode just for CD is a great idea, especially since one mode is unused now.
 
Grahf said:
I don't think we should touch Mode 1 as it would most likely break DVD games. However, adding a new mode just for CD is a great idea, especially since one mode is unused now.
Click to expand...
I was talking about a test branch, it would have nothing to do with the official master branch. Just something I can compile and test to see the effects.
 
Nah... Since we can know if a CD or DVD image is used, a combined mode would work quite fine as well!

The Mode 1 would limit it to 4x-DVD-Speed and 24x-CD-Speed and possibly add a latency for jumps for big sector-jumps...

No need for a duplicate mode...
 
Zarper said:
I was talking about a test branch, it would have nothing to do with the official master branch. Just something I can compile and test to see the effects.
Click to expand...
Yeah, but it's better to start with a new mode, so that there would be less work need if it helps.

I don't see why it wouldn't, really. It can't be a coincidence that the only games exhibiting such behaviour are on CD. The same thing happens with some PS1 games on PS2 if you set the disc reading speed to fast. Devs really optimized games like mad back then. If they knew it's going to be read from a CD, there might be code which is adjusted specifically for that speed. I think that in the case of Shadow Man we just have a situation where the level is loaded too fast and the game doesn't have time to load the textures.
 
TnA said:
Nah... Since we can know if a CD or DVD image is used, a combined mode would work quite fine as well!

The DVD-Mode 1 would limit it to 4x-DVD-Speed and 24x-CD-Speed and possibly add a latency for jumps for big sector-jumps...

No need for a duplicate mode...
Click to expand...
Sure, but maybe just whip up the easiest solution just to test if it even makes a difference first.
 
Sure, but for a fast test we could also recompile OPL with the read-spead-change applied to Mode 1 simply...
 
Whatever you guys feel is the best. It doesn't matter that much in the end, as long as this works out.
 
Works for me. Saw that sp193 linked to the code that does that earlier. But I will have to do some research to actually know what to change it to. If no one else does that I will try when I have the time.
 
BTW, what's the current status of Disaster Report/SOS: The Final Escape? I know it works fine with HDL 0.8c, but I'm not sure what sp193 meant in the earlier post. Is it still not compatible with OPL via HDD?
 
I thought he wrote a fix for it! Not sure, if it was for internal HDD or rather something like USB or SMB/LAN, tho'...
 
TnA said:
I thought he wrote a fix for it! Not sure, if it was for internal HDD or rather something like USB or SMB/LAN, tho'...
Click to expand...
It worked from USB and SMB to begin with. It was only crashing from HDD, although it was weird since it worked with HDL 0.8c.

If sp193 wrote a fix for it, it's integrated into the newest beta, right?

I wish we finally compiled all the fixes and squashed as many of the remaining problems as possible for a public 0.9.4 build. All of this is very chaotic with all the commits, special fixes, devices, etc.

EDIT: OK, got it.
rev1094 - SP193 - Added fix for SOS: The Final Escape/Disaster Report/Zettai Zetsumei Toshi. This also includes new IOP patch functions. - Tue Jul 24 18:09:42 2018 +0800
Click to expand...
 
The revisioning is at least not as chaotic as with FMCB/FHDB, with it's multiple re-releases (under the same version-number), which is the ONLY thing I really do not like in @sp193's FMCB/FHDB's-Handling/Policy!:-p
 
Grahf said:
BTW, what's the current status of Disaster Report/SOS: The Final Escape? I know it works fine with HDL 0.8c, but I'm not sure what sp193 meant in the earlier post. Is it still not compatible with OPL via HDD?
Click to expand...

The link to this fix and others is in the 1st post (Recent fixes tab).
After that version fix has been embedded into Ifcaro OPL.

To be add:
jolek said:
Here is my save, after completing the game and drinking ~100 liters of water:
http://www.mediafire.com/file/mfapt5bs2yb2dch/SLES_513.01.SOS+-+The+Final+Escape+.7z.
Click to expand...
 
You must log in or register to reply here.

Similar threads

Back
Top