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.
Either way, such behaviour is unintended. It usually costs nearly nothing to have proper synchronization mechanisms implemented, unless you want the IOP to drive something as crazy as 100Mbit Ethernet.
I meant to say that the direction that has to be taken, should be different. Instead of looking for bugs in OPL, the game should be checked for bugs. And then a suitable patch be written, if possible. Even if you emulate the behaviour of the CD/DVD drive, it'll be difficult to emulate the exact thread-switching on the IOP because we already add 1 more thread for at least OPL itself.
Runtime bugs are, however, hard to find and fix. Which is likely why it managed to slip past QA.
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.
Thankfully, I haven't found any game like that, except perhaps for Castle Shikigami II. But even so, it doesn't depend on the behaviour of the CD/DVD drive itself, but CDVDMAN's software behaviour; if reading was too fast and/or done in a continuous block, the game will fail to play any BGM. Hence mode 1 will also break up transfers into groups of 8 sectors.
Unlike the PS, no game is allowed to directly access the CD/DVD drive.
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?
It hasn't always been that way, which is why I wrote what I wrote.
Since Disaster Report was not working due to the sound driver being buggy in initialization and critical region protection, it was just a miracle that it even worked on its original media.
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.
USB is only slightly over 1MB/s. SMB is slightly over 2MB/s.
In practice, I never managed to get the CD/DVD drive to do over 2.8MB/s, which was why I used 2.8MB/s as a yardstick. Did not want to make it too low either, even though reading from CD-ROM could be slower. It's also only documented to be able to reach the maximum possible performance, only at the outer tracks.
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!
Some people seem to have stopped updating at v1.93-4. Perhaps because they found it confusing or what. So by doing this, hopefully some people will just update it when they download the new package.
