PS2 [Open PS2 Loader] Game Bug Reports

Can you send me rev 726...733?

I downloaded them from the competition :D http://www.ps2-home.com/forum/viewtopic.php?f=83&t=3
just scroll down a little, there are all old revisions starting from r501


i tested the betas and is in the r795 and r796 the last ones in which the NTSC-U version
of the game do not needs nothing for work.

The first time i tried the r796 i got a freeze, but maybe was casual, because later always worked
fine, except that i noticed that after an IGR the light of the HDD remais always on, which i

think is not normal, in the r795 this issue do not happens, maybe the problems started
in this revision.

I noticed the same thing on the PAL version with r726, the light remains on.
Yes, it's not normal. With newer builds the light turns off after IGR.

Btw with r726 the game works flawlessy. With r733 it can't pass through the loading screen (the light turn off as it should)
 
Daily build have different rev than from Ifcaro.
E.g currently there is 1220 Ifraro OPL rev, 1379 DB rev.
730 rev from Ifcaro can be 750 in DB.

I rather rely on Ifcaro builds.

I thought they were all in a team back at that time, therefore older revisions were the same.

So if it's like you're saying, r795/796 that @El_Patas tested could correspond to 726_DB If it's the case, probably there's no difference between PAL and NTSC game's versions

EDIT Btw, why DB revisions perfectly match what @sp193 said??
He said that the problem arise about r730. Indeed with r726 it works, with r733 it's broken.
 
Last edited:
So if it's like you're saying, r795/796 that @El_Patas tested could correspond to 726_DB If it's the case, probably there's no difference between PAL and NTSC game's versions

I don't know that, so I rather do not want to assume.
That's why I want to be stick with Ifcaro builds.

All I'm currently sure is that DB have got more rev than Ifcaro OPL.
 
Last edited:
3. Moved EE-side streaming support into CDVDMAN to avoid needing to use memcpy into the
CDVDFSV DMA buffer. SCEI had two sets of the streaming mechanism for the EE and IOP, but we
want to save memory for SMB support.
I think it's because of this.
 
EDIT Btw, why DB revisions perfectly match what @sp193 said??
He said that the problem arise about r730. Indeed with r726 it works, with r733 it's broken.
Because DB do not actively develop OPL, there is only one person that works on the core and it's sp193, so any changes to Ifcaro (even bugs) are present in DB cause they just take the changes.

DB is Ifcaro with another page tacked on to view psone games, that's all.

IMG_20190104_162121.jpg
 
Last edited:
You may find that the game "worked" and then suddenly "stopped working" because the commits around there had a lot of problems. I was a fan of mega-commits, which (unfortunately) made my work quite messy.
Then there were also some very drastic changes that I could not find a way to split up (i.e. replacement of EE core). Some issues stayed on until around r800.
v0.9.3 was released sometime in 2016, so all these commits were made a long time ago.

Until only recently, it became possible for OPL to interrupt an ongoing transfer when the user invokes IGR, which will be why the HDD activity LED stays on.

I think it's because of this.
No, that's for streaming.

I think it was commit 624f9a5. It used to call "sceCdRead0" to read data, in a lot of places. That function actually reads data from the calling thread, rather than letting it sleep.

Daily build have different rev than from Ifcaro.
E.g currently there is 1220 Ifraro OPL rev, 1379 DB rev.
730 rev from Ifcaro can be 750 in DB.

I rather rely on Ifcaro builds.

The most accurate way to find the commits, is to access the old Bitbucket repository.
The ps2-home edition of things only begun in mid 2015 or so, so the earlier commits should match the Ifcaro Github repository. But if not, then they also did something else...

Commit hashes will uniquely identify commits and match across repositories, as long as there were no commits changed in-between. Revision numbers might change.
 
Last edited:
I remember that it was sometime around r730 or so, I was fixing some problem with OPL mode 2 always being "on" for accesses to the cdrom0 device. But as a side effect, some additional games seemed to need mode 2.
THX for answering this question...
It would be quite interesting, if someone would track down the build, when it (State of Emergency) started to need/use 'Mode 2' (or these other modes)!

I suppose that change could have caused the issues and 'need for modes' on games previously compatible with less modes.
It came up due to @Grahf mentioning, that Mode 2 is absolutely necessary on new versions and that I did remember this exact bug!

It is worth noting that OPL's critical region protection does not totally work exactly the same as it does in the original CDVDMAN (which might be why it's now like that),
Hm... Might it be...faulty?!?

but I decided to not fix this because it could (again) drastically change the game compatibility list.
O.k.

The system works... but things could just work differently.
The commits around r730 could be severely bugged as well, so a direct comparison for game compatibility might be not really possible.
Well I would be VERY much interested, if it also were around these versions, where the compatibility-modes changed for a lot of games (and for more than Mode 2 as well)!

I think this is more about the HDD size and/or where the game gets placed on the HDD physically.
Well, yes this can have an effect possibly.

Also, State of Emergency is only ~550 MB, but the disc image is about 4.5 GB for some idiotic reason (should have been a CD game). Maybe it has something do to with this strange behaviour.
True, but that wouldn't apply to an SSD (no seek-times) and I can confirm that pretty mich the same modes are needed...

I tested the NTSC-U version (SLUS-20214) and the game freezes also for me in the
loading screen after the memory check, but works fine just using only MDMA 2.

I tested the game in OPL 0.9.2 and works fine without nothing, in OPL 0.9.3
and r1220 works fine with MDMA 2.

The PAL version (SLES-50606) works fine in all OPL versions without nothing.

Best regards.
Very interesting! It seems to be very much setup-dependent!

So, like sp193 was saying, this is most likely because there was a bug before that version which would cause Mode 2 to be always "on" for accesses to the cdrom0 device. This makes sense because the game doesn't work for me at all without Mode 2.
That can but does not necessarily need to be the case! I ought to remember, that there have been a lot of changes in a relative short amount of time which also changed compatibility-modes of a lot of games quite drastically...

Some of those 'über-big' changes @sp193 did awhile ago! :lol:

At least until the fix for Shadow Man 2 and the Phantasy Star remake is implemented (one way or the other).
It would be interesting to test these (games) on those older versions/builds as well + those builds with a configurable CBT.

You've remind me something:
http://psx-scene.com/forums/f150/open-ps2-loader-project-v0-9-3-a-62141/index773.html#post1210748.
Can you send me rev 726...733?

I know that this game has been fixed:
http://www.psx-place.com/threads/open-ps2-loader-game-bug-reports.19401/#post-133857.
So at least I'll try if my problems also started here with my slim console.
THX for linking to these!

Hi @sp193,

i tested the betas and is in the r795 and r796 the last ones in which the NTSC-U version
of the game do not needs nothing for work.
THX for tracking it (the revision) down (so fast)! :)

The first time i tried the r796 i got a freeze, but maybe was casual, because later always worked
fine, except that i noticed that after an IGR the light of the HDD remais always on, which i
think is not normal, in the r795 this issue do not happens, maybe the problems started
in this revision.

But in which one the game always freezes unless i use MDMA 2 is in the r797.

This are the descriptions and links to the r796 and r797 in Bitbucket:

r796
Consolidated error codes, added error codes for HDD mode, sync'ed with updates to HDD and PFS
from PS2SDK
, added workaround for clone/compatible network adaptors and corrected UV coordinates
for texture-drawing.
https://bitbucket.org/ifcaro/open-ps2-loader/commits/89c80d5845628e040aba669c8e733c985ea07692

r797
Fixed and enhanced streaming support:
1. BUG: sceCdStRead() incorrectly updates the remaining amount to read.
2. BUG: sceCdStRead() may lock up because it clears event flag bit 8 after ReadSectors() is run, but
the drive might have re-set the bit before that is done.
3. Moved EE-side streaming support into CDVDMAN to avoid needing to use memcpy into the
CDVDFSV DMA buffer. SCEI had two sets of the streaming mechanism for the EE and IOP, but we
want to save memory for SMB support.
4. Changed the reading thread signaling system back to using a semaphore because the streaming
callback (run from reading thread itself) could not issue another read request directly.
The use of SetAlarm introduces a needless delay.
https://bitbucket.org/ifcaro/open-ps2-loader/commits/f11cce2a15c2f0973a89ee33fc9f5f025ee07eb3

Best regards.
THX for tracking it down! I marked something, which might be related.
Most of the 797 changes could affect threading, tho'...

I am also marking something, which might be related to my first post on Page 16...

@jolek:
You both are still partially off, because the 'speed' of the standards (i.e. Bandwidth) you 2 are talking about, is very unlikely to be the cause of any issues, but rather the 'ping'' between the devices... (i.e. answer-time/callback-time, but not even necessarily on the cdvd-emu-driver, but rather the driver which manages the connection between the PS2 and the HDD or the HDD-Driver), causing another threading...

In the end, the 'threading' and how it can affect 'answer-times', probably is the issue-culprit and the threading is affected by ALL of these tests, since page 6!

That various setups and various builds affect these specific modes is a very clear indicator, that those 'speeds' (bandwidth and answer-time) and some other things seem to indicate the above. This Thread-time-variations are also one cause of why it is impossible to make a 100% accurate cdvd-emu-driver.
I might be wrong on the timing-thing, but I think the changes in the builds @El_Patas tracked down, MIGHT be causing issues 'in tandem' (like I explained earlier), but only if certain conditions are met (like the game-code-structure triggering it, or too much speed, etc.).


Edit: I have just seen the new comments! Yes, @sp193's Mega-commits! :D


Edit.2: Aaawww... I can't mark some sentences in color inside quotes? Hm...
 
Last edited:
Old revisions seem to be the same though (Ps1 page appeared just a year ago or even less…).
was called the ELM page before that, same thing though.. or maybe they just compiled beta builds for the public at some point before that? I don't know the full history
 
was called the ELM page before that, same thing though.. or maybe they just compiled beta builds for the public at some point before that? I don't know the full history

I checked the DBs page but I can't find on which build the project started.

Btw, it's probable that builds before mid-2015 match the git-hub ones, as SP193 was saying.
 
I'd be very interested, if the newest PR (awaiting merge) fixes some of these problems/issues with some games! :)
 
Please wait for #166, for State of Emergency.

was called the ELM page before that, same thing though.. or maybe they just compiled beta builds for the public at some point before that? I don't know the full history

It was POPS/PS1, then it became ELM.
You're right to say that even further back, it used to be just a line of builds for power users to test. Daily Builds (R) probably first appeared in 2014. Before that, it was prohibited by the original developers for anybody to compile development builds for other people to download and use.

I checked OPL 0.9.2 (r672): http://www.ps2-home.com/forum/viewtopic.php?f=13&t=43 it matches to the one from ifcaro repository.

OPL 0.9.3 r851: http://www.ps2-home.com/forum/viewtopic.php?f=13&t=150 (every version: clean, VMC, PS2RD, etc.) instead is different.

You need to look at the commits, not at the builds they make available. When OPL is compiled, we can specify the additional features that we want.
 
DB is Ifcaro with another page tacked on to view psone games, that's all.
+a custom theme + some other small changes (some of which actually can affect game-compatibility).

What the freakin' heck should that symbolize, lol?!? :D

Please wait for #166, for State of Emergency.
Greeeaaat... That's seems to be the perfect solution/fix as it seems that it doesn't need a new mode, doesn't waste a lot RAM and might even fix issues in more than one game! Great!

How one line or string within the code can change some games behavior, lol!

Daily Builds (R) probably first appeared in 2014. Before that, it was prohibited by the original developers for anybody to compile development builds for other people to download and use.
...and it was for a reason, which worked quite well tho' (given that the PS2 is a weird platform to develop on)... To introduce more people into the PS2SDK and development on a PS2, was the main-purpose + to avoid false negatives and bad tests from users who have no clue, what they are doing!


Btw.: #ninja'd #Daily Builds® #zen configuration/combination®;)


@El_Patas: I am eager to hear from your test with this PR and a merge, if it works! :)
 
Last edited:
You need to look at the commits, not at the builds they make available. When OPL is compiled, we can specify the additional features that we want.

I simply checked the MD5s ;)

@TnA I read the topic in git-hub: https://github.com/ifcaro/Open-PS2-Loader/pull/166

About GT4, you want to solve the problem at the root, right?? Because You know, you can permanently fix this since ever just cold loading the HDD with Ule (any version, just access hdd0 from filebrowser). It seems that certain OPL versions already solved (just cold booting to them).

If you have FHDB the procedure is a little different (you must avoid FHDB to start your HDD).

O.T. Someone with the Sony NA with a sata board can make the HDD-spindown function to work?? I've the HDD device set on auto, but sometimes when doing cross tests/or just playing from USB I would prefer the iHDD to not uselessly spin.
 
That's neither a fix nor the root of the issue, but only a trigger (again)!

You focus too much on cosmetics, which won't actually fix the real cause of a problem!

It is interesting to know, that coldbooting still affects some games, tho'!
But that is a workaround and also not a proper fix.


A proper fix doesn't require the user to do any kind of awkward things (like coldbooting a PS2, solely for a game to be working)...! ;)
 
Last edited:
Back
Top