PS2 [Open PS2 Loader] Game Bug Reports

[Grahf]

I only have Shadow Man.
Anyway could you also test this game through ETH and HDD?
You can try it with "my" values?
OPL 0.8 for SMB, 1.5 for HDD with Demo mode.
After selecting language, wiat ~1 min at Press start button "page".
After ~1 min, demo mode should starts. Graphical glitches might appear at the end of this demo.

I will test it with HDD, but I can't do it over ETH since I don't have it configured right now and I can't really unpack the Win XP PC and connect everything easily.

 

[Zarper]

The CD player might be slow, but it's not 800 kB/s slow. Hence me bringing up that converting the game into a DVD, that is even faster, still works. I don't see how that logic is hard to follow.

And yet again, I have never said, and no one else have ever said, NOT to use the fact that this works.
If a single common acceptable speed can be found, I guess it would not be hard to incorporate this into Mode 1. But if speed varies from 500 - 1500 kB/s, then maybe having an option is preferable.

 

[Grahf]

The CD player might be slow, but it's not 800 kB/s slow. Hence me bringing up that converting the game into a DVD, that is even faster, still works. I don't see how that logic is hard to follow.

And yet again, I have never said, and no one else have ever said, NOT to use the fact that this works.
If a single common acceptable speed can be found, I guess it would not be hard to incorporate this into Mode 1. But if speed varies from 500 - 1500 kB/s, then maybe having an option is preferable.

Because it's never about perfect emulation: we simply can't achieve that. Also, as @jolek just told us, Shadow Man does not work with ESR, so your logic can't be followed either in its case.

To begin with, we are talking about different kinds of media storages and reading methods. It's incomparable in details. We can only make rough estimates. We know the DVD speeds are too high, so we need to lower them until it works without issues. We can't even say how fast a game like Shadow Man reads data from an original CD. The speed would change dramatically depending on where on the disc the laser must read, etc.

 

[TnA]

@TnA I told you at least three times before: I know you mean the actual mode itself,

...and you have just proven, that you did NOT understand, what I was referring to...

not the empty slot, but with such a simple compatibility mode the RAM usage would not increase to the point of breaking other games.

...and again...
I am:

• NOT talking about the Compatibility-Mode-Slots (the 'choice of modes' in the GUI)...
• NOT talking about some RAM-Changes an additional Mode would cause... (probably none)
• NOT talking about the emulated cdvd-speed... In fact I supported a change!
• talking about your suggestion of a 'correct reaction of the/OPL's cdvd-driver to faulty games' instead of 'patching them ahead of time'...

Do you finally understand?!? Can you understand the words, I am writing? I am sorry if my explanation lacks detail, but English isn't my native tongue...

Maybe someone else will make you understand, why that suggestion of a JIT-reaction, instead of a AOT-Patching is just not a good idea for OPL!

I already stated all of these things multiple times in my previous replies.

You are blowing things out of proportion.

No... You are telling me the same sentence over and over again, like a chat-bot... I am able to understand it the first time (most of the time). You did not yet understood it (what I am really referring to), after more than one explaination...

You do not even understand WHAT I am talking about, so how can you make a qualified claim or even an assumption, how much a structural change would affect the software?

You have got 0 clue about the hardware and software and how it works.

Besides, it can always be tested since we're talking about a beta build.

Agreed! The transfer-speed-'limiter' should definitely be tested.
But the speed might not be the cause, but only a trigger! It is the best, to fix the bug and not 'work around it'.

Adding manual values input to Mode 1 is a lazy solution

Why? It would give the end-user a lot more freedom and values to test with? If we find a value, which works well for all games thisnvalue-change-entry can simply be removed again and the value hard-coded ESPECIALLY since we are in a beta-stage...

and it would confuse the hell out of most users. We should find optimal values and try to add a compatibility mode just for the problematic CD games.

Agreed on the 'optimal values', but about the 'confusion'-part... It would be used sooooo seldomly anyway, lol... Not a real problem and much more versatile for testing... But yes, removing it later (like how it was done with cdvd-callback-timer before) is desired! Hyper-compatibility, with as few modes as possible is desired anyway!

I don't see how I can make this any clearer. You have to first convert the CD image into a DVD image. ESR doesn't work with CD images or CD structures. Have you ever used a CD game with ESR?


If it's so simple, why couldn't ramapcsx2 just lower the read speed, shouldn't be that hard to do in an emulator? I'm not saying to not use the fact that it works with lower speeds. Just that I'm not convinced that's the root cause.

I agree to all the things you've mentioned...

With optical media, there are too many variables. We have no way of accounting for all of them. Like a) the kind of optical media used b) the quality of optical media used c) burning speed d) burner quality e) burner firmware f) the number of working hours of the PS2 drive g) possible dirt and/or dust in the PS2 drive. Besides, ESR shouldn't be a template here. We should only observe how original discs behave on healthy drives.

Indeed and all true... But he mentioned it, because ESR also has some code loaded during runtime, just like OPL... An original game solely runs its game-code.

So there is a valid point of him bringing up ESR, especially because you claimed it is because of higher read-speeds (a.k.a. 'transfer-rate/bandwidth), while it actually also could be because of the faster and slower response-time of the devices. You claim it, without any further proof... You claim it to be factual (without any evidence)... That is a problem!

When I was using the PS2 CD/DVD image generator program, I could burn CD images to DVD discs and they still retained their CD structure. It was basically tricking the drive to read a CD from a DVD disc.

That's a FALSE claim! They will not retain the same LBAs, nor the same sector-data and sector-size (2352Byte-Sector+Subchannel-data vs 2048Byte-Sector)! A PS2-CD is also Mode2/XA Level 1 and a DVD is Mode 1 Level 1...

You do know those disc-standards, or not? You should know them, if you are talking about these kind of things, or you are just claiming unverified and wrong things and thus are spreading misinformation.

I was long, long ago, but from what I remembered...
This game checks LBA, when you convert this game from CD to DVD, it'll not boot.
It'll not work with ESR, because it is on DVD.
It'll work with swap magic with CD, but not with DVD.

Indeed, which is proof that it has NOT the same structure...
If it had, EVERY CD-based game, could easily be converted to DVD and ALL of them would run, if it would read it like a CD...

I don't know why we are even talking about ESR here. It has no bearing on OPL. We only need to compare with original discs working on a healthy PS2 drive.

Wrong... He brought up a valid point/example, because ESR has some code running (just like OPL), which runs 'beside' the game's code... Original games do not have that, so in regards to that ESR is an alternative/example... USBA, HDL/HDA and PS2ESDL would be viable alternatives/examples as well.

Whether games like Shadow Man and the PS remake are buggy or not, the fact is that somebody programmed them that way and they work from start to finish on real hardware.

First off,... No... Not even that, even tho' it is intended to work that way... Try an original Tekken 4 on a SCPH-750XX (or was it SCPH-770XX)...

Second... Some games did have occasional hickups or even freezes, due to their bugs, even on original discs and hardware... It's not so often, but it happens due to these kind of bugs... It would be ludacris to adapt and add code for their faulty behavior, instead of patching them, because it wouldn't yield any benefit, but only disadvantages!

Since we now know it's all about the timing,

Oh... Now it's the timing... Previously you pointed/referred to the bandwidth...

I don't see a point in trying to patch the games since we already know others have tried for a long time and couldn't do it.

Does that exclude others from being able to do it, if they really try to? No!

It's always the best way to emulate the original hardware behaviour if possible.

Indeed, I agree!
But it is not possible! We have to spare as much IOP-RAM and CPU-cycles as possible! There is a reason, why we sacrificed the Filesystem-driver in-game and why games on USB need to be defragmented... The reason is sparing IOP-RAM and CPU-cycles.

In this case, it's a simple fix, not an elaborate one. Realistically, how much the RAM usage would increase if we added a duplicate of Mode 1, but with hard-coded speeds for these CD games?

Like I ELABORATED, this is not what I was even talking about... Maybe you did understand now, what I was really referring to or should I quote your exact sentences?

 

[TnA]

To begin with, we are talking about different kinds of media storages and reading methods. It's incomparable in details. We can only make rough estimates. We know the DVD speeds are too high, so we need to lower them until it works without issues. We can't even say how fast a game like Shadow Man reads data from an original CD. The speed would change dramatically depending on where on the disc the laser must read, etc.

Oh... Now that changed as well... I thought it would read the DVD just like a CD?!? That was your statement.



On another note: Please don't 'quote' me on things I had never written, like you did on one of your previous replies...

 

[Grahf]

Do you finally understand?!? Can you understand the words, I am writing? I am sorry if my explanation lacks detail, but English isn't my native tongue...

Maybe someone else will make you understand, why that suggestion of a J It-reaction, instead of a AOT-Patching is just not a good idea for OPL!

It's ridiculous that you do not understand that I'm talking solely about these two CD games, which are incompatible with OPL still in 2018, after all these years. If we can squeeze in one more compatibility mode for them - which we can - then we should do it. This does not suggest that we should treat ALL problematic games this way. Can you stop being so offensive and telling people they can't read when, in fact, it's you who jumps to conclusions and blows things out of proportions?

Why? It would give the end-user a lot more freedom and values to test with? If we find a value, which works well for all games thisnvalue-change-entry can simply be removed again and the value hard-coded ESPECIALLY since we are in a beta-stage...

Because we need to find the optimal value beforehand. It's exactly how the current Mode 1 was created. sp193 and randal put a lot of work to find an optimal value for DVD games. In the past, the CBT value was to be entered manually, too, but that was a lazy solution and very confusing for most users + it made compatibility lists chaotic.

That's a FALSE claim! They will not retain the same LBAs, nor the same sector-data and sector-size (2352Byte-Sector+Subchannel-data vs 2048Byte-Sector)! A PS2-CD is also Mode2/XA Level 1 and a DVD is Mode 1 Level 1...

You do know those disc-standards, or not? You should know them, if you are talking about these kind of things, or you are just claiming unverified and wrong things and thus are spreading misinformation.

+

Oh... Now that changed as well... I thought it would read the DVD just like a CD?!? That was your statement.

You are obsessed with nitpicking. This isn't an attempt to write a technical thesis on how disc storages operate. Technically, things like LBA need to be changed, but a CD game still is just that. These tricks do not rebuild the games. CD games might have things such as dummy files just to optimize disc reading speed and that's still going to be exactly the same if you convert them to a DVD disc image and burn using a DVD-/+R. The files will be organized in the same manner and the game code will work identically. The PS2 will just be fooled into using the DVD-ROM to read a CD game. Can't you understand what I've been saying all along? That's why Shadow Man still doesn't load textures via ESR: it's still a CD game, just with PS2 being fooled into reading it from a DVD disc. Calm down, dude. It will be much easier to talk with you that way.

Oh... Now it's the timing... Previously you pointed/referred to the bandwidth...

Anybody can read the post history here: just like all of us, I didn't debug Shadow Man: 2nd Coming and I don't know EXACTLY what's going on, but ramapcsx2 suggested it's a timing issue caused by different reading speeds between CD and DVD games on PS2. It has also been settled that the DVD drive in PS2 is too fast for this game (for some reason, likely timing issues).

 

[jolek]

For me, debugging these games will be the best option.
Who knows what will happens e.g. in half of the game.

 

[Grahf]

For me, debugging these games will be the best option.
Who knows what will happens e.g. in half of the game.

ramapcsx2 couldn't do it & he had put so much work into PCSX2. Do you really think anybody here will put the time needed to debug this game (and the PS remake)? I'm convinced it will work all the way through if it loads the textures in the first level. It's just about the reading speed - that's why it works from USB, just like ramapcsx2 said.

BTW, I will post the results of my test with Shadow Man soon. It's looking pretty sweet.

 

[jolek]

ramapcsx2 couldn't do it & he had put so much work into PCSX2. Do you really think anybody here put time to debug this game? I'm convinced it will work all the way through if it loads the textures in the first level. It's just about the reading speed - that's why it works from USB, just like ramapcsx2 said.

It's only a suggestion, no one needs to do it.

Some of textures are missing in demo mode, but they are "available" in 1 level,
when I use e.g OPL 1.6 from the package that Zarper provide.

Anyway, what is the average speed for USB in latest OPL (1200)?
Is it quicker than 800 KB/s?
Different devices might have different values, maybe also access time counts?

 

[sp193]

Gentlemen, there is no need to nitpick on the actual terms used. I know it can be annoying when somebody tries to push an idea with no actual plan, but @Graf's ideas aren't totally unfounded. It is true that when we only consider the devices used, one would actually focus on the throughput of a device.

However, my experience with fixing these games tells me that sometimes it is not always a timing problem related to when transfers complete (due to speed), but sometimes the changes we make to the IOP kernel will already break buggy modules by the game developers, simply because it was a miracle that their code even worked on the real hardware. Unlike modern OSes, this thing uses non-preemptive multitasking, so even adding a thread could change when the existing threads would change operational states. The new devices that we add to the system, also require CPU time to service, which affects the sequence of events that occur on the IOP.
Perhaps a solution to this, would be to actually not change anything in the IOP, which means some accurate hardware emulation similar to PSIO...

Sometimes, the bug doesn't even exist on the IOP, but on the EE. It triggers because the IOP RPC calls take a different amount of time to execute, causing the sequence of events on the EE to change.

The CD-ROM is just the media. The API offered are also exactly the same, although the underlying execution is different. The documented transfer rates are slightly diffferent, but I don't recall managing to make any game more compatible by lowering the emulated transfer rate below 2.8MB/s. So I do think it is more likely to be just a bad coincidence that there are a number of CD-ROM games that aren't compatible with OPL. But if it is possible to make mode 1 more accurate, then please do. It would be even ideal if we can be independent of the DMA mode setting.

It is also true that perhaps there are a number of titles like that, although it is not significant when compared to the size of the PS2 game library.

So to understand what needs to be done, even if it is not about changing the game, it is perhaps still necessary to look into why the affected games do not work well under OPL. Even if it is OPL that needs to be changed.

 

[Grahf]

Perhaps a solution to this, would be to actually not change anything in the IOP, which means some accurate hardware emulation similar to PSIO...

Well, OPL is truly great and with some more tweaking, its compatibility will be extremely high. PSIO-like devices are very expensive to produce, so the retail price is even higher. Plus, offering such products means you have to deal with a lot of people and their problems. It's only good if you run a company, and then you're running the risk of being sued by Sony.

I just tested Shadow Man via HDD and my results are identical to @jolek's. The game works perfectly with "OPL 1.5". This speed not only loads all the textures, but also fixes the problem with voice overs ending abruptly. Since merely changing the reading speed fixes this game (and the Phantasy Star remake, as reported before), we can definitely say these games are coded for the timing of PS2's CD-ROM drive. Perhaps this was intended by the developers to optimize load times from a CD? They knew how the drive in PS2 will behave, to the point of knowing where the laser head will have to go to access a particular file. Maybe this simply was the best way for them to ensure smooth load times across the whole game?

@Zarper Can you check the Phantasy Star remake with "OPL 1.5", to see if the same speed which fixes Shadow Man works?

 

[jolek]

@Zarper Can you check the Phantasy Star remake with "OPL 1.5", to see if the same speed which fixes Shadow Man works?

First, going bellow 1000 kB/s seems to mitigate the issue. Haven't been able to get any corruption in Phantasy Star yet.

I just tested Shadow Man via HDD and my results are identical to @jolek's. The game works perfectly with "OPL 1.5".

With Shadow Man - 2econd Coming SLES_504.46, mode 1, through SMB most of textures are available with OPL 1.0 and 0.9.
0.8 seems to load all textures.

Through HDD, mode 1, textures starts to appear with OPL 1.6.
With 1.5 all textures should loads.

So currently the best results compatible with all devices is OPL 0.8 from Zarper package.
I mean this speed will work with Shadow man through ETH and with Phantasy Star remake (through ?)...

BTW this speed will also allow Castle Shikigami 2 to have BGM.
Although I haven't tested Shadow Hearts with it.

 

[Zarper]

I've been using HDD for testing. Will try ETH during the day.

 

[Grahf]

So currently the best results compatible with all devices is OPL 0.8 from Zarper package.
I mean this speed will work with Shadow man through ETH and with Phantasy Star remake (through ?)...

BTW this speed will also allow Castle Shikigami 2 to have BGM.
Although I haven't tested Shadow Hearts with it.

0.8 is very slow to use on HDDs, unless it's really the only possible speed. With Shadow Man, I can notice more slowdowns when the speed is below 1.5.

Although I haven't tested Shadow Hearts with it.

We can't use such low speeds with DVD games - it would unnecessarily bring down their performance and extend their loading times. We need two modes - one for CD and one for DVD.

BTW, @jolek, great that you have tested Castle Shikigami 2. It's yet another CD game, so we all see a pattern here: CD-based games for PS2 were supposed to have lower reading speeds and it was just an oversight during OPL development since everybody was thinking about DVD games.

I've been using HDD for testing. Will try ETH during the day.

You're saying the PS remake won't work with "OPL 1.5", like Shadow Man? Only below 1.0? If yes, how about something like 980 kB/s? We need to find the highest working speed for each game. No point in slowing them down too much.

 

[jolek]

0.8 is very slow to use on HDDs, unless it's really the only possible speed. With Shadow Man, I can notice more slowdowns when the speed is below 1.5.

Currently it's only a workaround of a problem.
If it's working fine with SMB and HDD that's the way it should be done.
Also the same speed will able Phantasy Star to work with HDD, so we will have "full compatibility".

BTW, @jolek, great that you have tested Castle Shikigami 2. It's yet another CD game, so we all see a pattern here: CD-based games for PS2 were supposed to have lower reading speeds and it was just an oversight during OPL development since everybody was thinking about DVD games.

Castle Shikigami 2 works also previously with mode 1.
So it's just a curiosity.

It might be not oversight because Phantasy Star works great with ESR.
Shadow man doesn't.

Phantasy Star works great with ESR once you've converted it to a DVD. And that should be a lot faster than 1 MB/s. Also it works a lot better without the current Mode 1 than with it. Which would suggest something other being the real problem and this just being a work around.

I've checked Shadow Man - 2econd Coming with ESR...
It has the same problems (textures missing) as OPL through ETH, HDD.

 

[Grahf]

Currently it's only a workaround of a problem.
If it's working fine with SMB and HDD that's the way it should be done.

That's not a good solution for HDD devices. There should be a new compatibility mode added which would pick the optimal speed per game and per device, unless we can find something optimal. Shadow Man works awfully with those low speeds. I can see framerate dips when the camera is moving if the speed is below 1500 kB/s. Below 1000 kB/s, the dips are even more severe.

Also, it's not a workaround, actually. We're trying to emulate real CDVD behaviour. That's not a workaround. That's exactly what we should be doing.

Castle Shikigami 2 works also previously with mode 1.

I know that, but there were concerns these low speeds would break other games. As it shows, other CDs games still work, so it's not just for Phantasy Star and Shadow Man, but for all CD-based games on PS2.

@jolek, can you check Star Wars: Racer Revenge now? It's also a CD game. Start with 1500 kB/s ("OPL 1.5") if you can.

 

[sp193]

BTW, @jolek, great that you have tested Castle Shikigami 2. It's yet another CD game, so we all see a pattern here: CD-based games for PS2 were supposed to have lower reading speeds and it was just an oversight during OPL development since everybody was thinking about DVD games.

No, it's not a problem with speed. Accurate Reads mode (mode 1) isn't just about limiting transfer rates, but it also breaks up transfers into groups of 8 sectors.
For this game, the sound driver will occasionally check on the read position with sceCdReadPos(). If it fails to notice a small-enough change in the read offset, it fails to continue BGM playback. This is just a bad coincidence with the media type, as this bad design can also be implemented for games on DVDs. If you removed the transfer length limitation, this game will fail to play its BGMs, even if you limited speeds as slow as you liked.

Also, it's not a workaround, actually. We're trying to emulate real CDVD behaviour. That's not a workaround. That's exactly what we should be doing.

No, you're working around something, game bug or not, if it actually has one. The PS2 has a 24x CD-ROM drive, not the 10x CD-ROM drive from the PS.
But it is true that mode 1 is really for that - to work around bad game designs where possible. It doesn't cost much to design the game to work properly with the hardware. This isn't the same as optimizing the game to squeeze as much as possible out of CPU cycles or the architecture, as we only have to make API calls to tell the drive to do things in the background. Not to mention that it is the IOP that talks to the hardware, not the EE. Neither does the EE actually poll on the drive to check whether it's done either (it checks the RPC status, hence avoiding any need to get the IOP to ask the CD/DVD drive for its status).

But if you can actually find a game that is so pressed for performance that it wasn't possible to make proper synchronization a thing, then that will be interesting.

 

[Agrippa]

Meinnn Gottt, man. Here's the OPL compatibility list maintained by fellow Frenchman:

https://docs.google.com/spreadsheets/d/1MLEw7TIKvn9MCwd5Ptbqh2lkUj3lX6YQ2wPgLEx8Koo/edit#gid=0

You can easily find there which CD games are working with various configurations. I've looked quickly and have seen very good compatibility (only few games of 77 need some modes or disabling VMC/IGR). So your point with special working condition for CD games is wrong. There's indeed problem with the textures of that game, but it's just a coincidence the problem is resolved by limiting transfer rate. There's no specific CDVD behaviour there other than sh** coding by the developers.

 

[Grahf]

No, you're working around a game bug, if it actually has one. The PS2 has a 24x CD-ROM drive, not the 10x CD-ROM drive from the PS.

What if the game was designed this way? This is very common on closed hardware. For example, early C64 games used a bug in the SID sound chip to generate certain audio. When Commodore fixed the chip, those games became partially incompatible. If people feel like fixing game code, then great, but if we can emulate the CDVD and these game become fully playable, just like on the real CDVD, then what's the problem with it?

I've looked quickly and have seen very good compatibility (only few games of 77 need some modes or disabling VMC/IGR). So your point with special working condition for CD games is wrong. There's indeed problem with the textures of that game, but it's just a coincidence the problem is resolved by limiting transfer rate. There's no specific CDVD behaviour there other than sh** coding by the developers.

Of course it's not a confidence. More CD games have issues (like Racer Revenge), just that it was never checked thoroughly. There is a specific CDVD behaviour. The CD-ROM in PS2 is slower than its DVD-ROM, so CD games work with slower reading speeds on real hardware. These games were tested by their developopers for real hardware and that's why they start to exhibit issues when subjected to higher transfer rates. Buggy or not, that's how they work.

 

[Zarper]

What if the game was designed this way? This is very common on closed hardware. For example, early C64 games used a bug in the SID sound chip to generate certain audio. When Commodore fixed the chip, those games became partially incompatible. If people feel like fixing game code, then great, but if we can emulate the CDVD and these game become fully playable, just like on the real CDVD, then what's the problem with it?

Of course it's not a confidence. More CD games have issues (like Racer Revenge), just that it was never checked thoroughly. There is a specific CDVD behaviour. The CD-ROM in PS2 is slower than its DVD-ROM, so CD games work with slower reading speeds on real hardware. These games were tested for real hardware and that's why they start to exhibit issues when subjected to higher transfer rates.

Intruding delays in reading really isn't the same as emulating the CDVD. That is likely why different games, and even different interfaces on the same game, seem to need vastly different speeds.