For you two to better understand this issue I'll explain what I grasp from how OPL CDVDMAN works and whay exactly I did to it:
CDVDMAN is a driver and as such is accessed by other threads through imports.
Games call functions such as:
And a lot, lot more. Talking to SP193 we had the idea of adding a thread delay on sceCdRead0() which caused the compiler to insert some code on that routime, making it slower.
The nature of the bug on DDR and Pop'n Music games with "sddrviop.irx" is exactly what Bat Rastard mentions on his latest message.
Regardless of the real effect of putting that on the source have, I am believing that the added (ASM) code is helping to slow down the thread or to "bump" something inside of the IOP, making the problem go away for the games using "sddrviop.irx". Good. But then it broke or had side effects on games that use the sceCdStRead() function. (Onimusha 2 was the perfect case here) To help with that I cloned sceCdRead0(), which is a artificial function added to the CDVDMAN so it can translate accesses to the regular sceCdxxx() functions into HDD accesses and the clone function has no mention to ThreadDelay().
Now I have a "dual buffer" of sort on CDVDMAN which I can take other redirections and choose where I should redirect to sceCdRead0() or sceCdRead1().
On the current test version I restored sceCdRead0() to have no delay and changed sceCdRead1() to have the delay instruction. And I'll try replacing each function with the delayed or keeping the non delayed version to see where it causes problems.
Also, you can look into the trouble making games ELF files and check what exact kind of CDVDMAN imports it uses. PCSX2 is PERFECT for this purpose, also.
So consider this a work in progress, please.
SCPH-10000_GH-001 SCPH-15000_GH-003 SCPH-18000_GH-008 SCPH-30001_GH-005 SCPH-30000_GH-016(V4) SCPH-30001_GH-010(V4)
2xSCPH-10190, 2xSCPH-10350, 2xSCPH-10280
"**** j0 hackers!"
-Sjeep (As seen on TOXIC OS ELF...)