PS2 [Open PS2 Loader] Game Bug Reports

I tried combining 1+2. Since USB seems to work, I figured the problem would be with the reading and not OPL fixes like the other modes.

That's why I specifically said SATA-HDD, it's read from a Gamestar adapter using a HDD. SMB however is from an original Sony NA.
 
Omg MDMA-Mode
puQNst2.gif
 
I've seen a report from 2010 saying that Phantasy Star generation:1 is working with OPL 0.6 SMB. However, the oldest version I can get to work over SMB is 0.8. The issue is a bit different in 0.8, but still there.
If I'm able to confirm it working in 0.6 I was thinking I could set up a build environment and bisect it.
Are there any special things you need to do to get games working over SMB in 0.6 and 0.7?
 
You may be looking at a game bug. A lot of the issues you may find nowadays, are caused by bugs left by the developers.
 
The game is reported working as expected on unmodded console, chipped console, ESR and I haven't gotten it with OPL USB.
 
As different versions of OPL acted differently, I decided to track down the commits that were responsible for the changes. Hopefully it will help.

83d68fd
SMB: After first battle entire party gets a static noise rectangle over their face when facing downwards.
USB: After 1-2 battles PC and guards gets replaced with miss coloured battle screen textures that changes after direction and walking animation. Rest of party invisible except for shadows. (Same as picture from before)

405a1b2
SMB: Partial commit, can't start NA.
USB: Same as before.

1ec2f7c
SMB: After first battle entire party gets a static noise square over their body when facing downwards. (Same as picture from before)
USB: Same as before.

5 months later.

ed1dea7
SMB: Same as before.
USB: Same as before.

fce0909
SMB: After first battle PC and guards gets replaced with miss coloured battle screen textures that changes after direction and walking animation. Rest of party invisible except for shadows.
USB: Have not been able to reproduce the bug.
 
Last edited:
I tested with OPL 1200 +PADEMU+IGS since that was what I had on the MC at the moment.

With HDD:
1+6, 1+2+6, 1+3+6, 1+2+3+6 all were pretty much the same as just mode 1.

While I was testing I also tried mode 1 on an older build and didn't get instant corruption, I will have to test and see at what commit that happened.
 
So with OPL 1200 no matter how many compatibility modes you'll enable (1+6, 1+2+6, 1+3+6, 1+2+3+6),
game will act like it has got only mode 1?!
Does with OPL 1200 (corruption) graphical glitches occurs (with mode 1)?

What revision was that older version?
 
Yes, same static noise as in the picture from my earlier post.

ed1dea7
fce0909
Tried them since ed1dea7 was the last commit before SMB/USB changed with fce0909. Both worked at least better with mode 1 than 0.9.3+. Will have to investigate further.
 
Last edited:
ed1dea7 at github (rev678, commit 2a3d6dc at bitbucket):
- Updated OPL to be fully compatible (compiles without the deprecated warnings) with the HEAD revision of the PS2SDK.
- Sat Jan 11 20:27:05 2014 +0800.

fce0909 at github (rev679, commit e5e85f0 at bitbucket):
- Changed the EE core and updated some modules.
- Sat Apr 19 13:52:29 2014 +0800.

BTW rev672 it is stable 0.9.2 at bitbucket.
 
Last edited:
I am fully aware of this, although GitHub doesn't track commit number very well as far as I know. Is that a preferable way of communicating commits that change the behaviour of the bug than a link to the commit on GitHub?

Anyway, r679 seems like it fixed USB and made SMB worse. So something in that commit definitely did something. That's why I tried HDD with that commit and the one before it.
 
Beware that the OPL modes have not remained the same over the years. Mode 1 used to be Alt Storage location, as OPL used to have a really big EE core.

Mode 7 was once something else too, but I forgot what.
OPL also had worse performance before v0.9.3, due to it making really small reads. So any game bug that is related to faulty critical region protection may have seemingly better compatibility with older commits.

Some of the commits somewhere between the r700~800 were severely bugged (starting with that commit with the accidental "changes.txt" in the commit log). Sometimes due to the size of the changes that I was trying to complete, lack of skills and sometimes just a lack of clarity of what I wanted to do. I used to be a fan of mega-commits, thinking that there would be some penalty for having significantly more, but smaller commits.

For this game, I did look at how it did reading during the last weekend, by statically analyzing the code (didn't run it). It seems to use sceCdRead() and sceCdSync() where appropriate; most calls to sceCdRead() are followed by sceCdSync(). There is a command-queuing system, which seems to (but not confirmed) to automatically insert a command for sceCdSync() after each command for sceCdRead(). All calls to sceCdRead() are conducted with infinite retry attempts.

The game appears to be single-threaded, other than the Sony threads that are used for the kernel patches. It does not seem to use the libcdvd callback mechanism.

It also uses streaming, but I didn't really check the code for that because streaming is usually used for things that can be streamed - like audio and video. It also has a sound driver, but I did not check that either, since we're not looking for a freeze or bad audio.

It was also made with a late SDK release, which should already have the more major kernel bugs patched out.

Zarper said:
I am fully aware of this, although GitHub doesn't track commit number very well as far as I know. Is that a preferable way of communicating commits that change the behaviour of the bug than a link to the commit on GitHub?
Click to expand...

Commits are uniquely identified by the hash. Commit revisions may not remain the same, between repositories.
The use of commit revisions have gone back long in time. Back when OPL's repository used to be hosted on Bitbucket.

Since commit hashes cannot really indicate what came before/after, you can also mention the commit revision... if you can determine that... along with the hash. But Github has no function for indicating that.
 
You must log in or register to reply here.

Similar threads

Back
Top