PS2 [Open PS2 Loader] Game Bug Reports

[sp193]

http://www.psx-place.com/threads/open-ps2-loader-game-bug-reports.19401/page-3#post-144669
TLDR
On HDD with no modes set the issue is uncommon. Easiest to just restart the game if it doesn't happen within a couple of battles.
With lower transfer rates (Mode 1 or lower DMA) it corrupts after almost every battle.

SMB corrupts after almost every battle.

USB has no problem as far as I have been able to see since 0.9.3.

I see, thanks.

This is quite a strange issue. So instead of glitching due to faster transfer rates... it might be glitching due to more CPU-heavy transfers.
Yes, I was using the HDD, at UDMA mode 4.

It's a single-threaded game that doesn't really do much with the IOP, so there are less places for it to go wrong as well.

with caaeafb new apps scheme i keep getting kicked to browser, older scheme still working.

What device are you using? TBH I haven't tested it too much, as there is too much ground to cover.

Have you checked your title.cfg file to be sure that the filename is typed properly? It should only have the filename of the file:

title=LaunchELF v4.50
boot=BOOT.ELF

It is case sensitive, but this actually depends on the capabilities of the device driver for the device that the app is on. So I will say it is case-sensitive.

Also, Apps wont load if you use a setup with prefix like this.

Noted. Some adjustment has to be made to factor in the prefix option, which is user-configurable.

 

[Zarper]

I see, thanks.

This is quite a strange issue. So instead of glitching due to faster transfer rates... it might be glitching due to more CPU-heavy transfers.
Yes, I was using the HDD, at UDMA mode 4.

It's a single-threaded game that doesn't really do much with the IOP, so there are less places for it to go wrong as well.

Both HDD and SMB stops glitching with Mode 1 if transfer is limited to around 900 kB/s.

 

[Vedita BR]

What device are you using? TBH I haven't tested it too much, as there is too much ground to cover.

ETH

Have you checked your title.cfg file to be sure that the filename is typed properly? It should only have the filename of the file:

title=LaunchELF v4.50
boot=BOOT.ELF

Yes

title=uLaunchELF
boot=boot.elf

It is case sensitive, but this actually depends on the capabilities of the device driver for the device that the app is on. So I will say it is case-sensitive.

Boot name and file corresponds, both are lowercase.

 

[Peppe90]

I do not understand 2nd part.
You mean cold boot -> E1 launck keys -> OPL or wLe?
Or OSDSYS -> wLe -> OPL?

Yes, I must not enter the OSDSYS for the game to plays fine (with no sound problems)

NTSC or PAL?

NTSC-U

What loading screen?
After Press start button:

NTSC or PAL version?

Yes that loading screen. I'm using the NTSC-U version.

 

[Peppe90]

The game (Shawn Palmer's Pro Snowboarder) was already fixed though.

I was using OPNPS2LD-GAMELIST-3 and 4

 

[jolek]

Yes that loading screen. I'm using the NTSC-U version.

I don't know what is going on, but recently we have got almost different experience.
I can easily pass this screen, with mode 2, start race, etc.
However I'm using PAL game on PAL console.
Tested with OPL 1250 through SMB.

 

[El_Patas]

@sp193,

I tested the NTSC-U version of the game "Ferrari Challenge: Trofeo Pirelli" and worked
fine after the IGR.

I tested this versions of the game "Shaun Palmer's: Pro Snowboarder":

NTSC-U (SLUS-20199)
PAL-English (SLES-50400)
PAL-French (SLES-50401)

After the IGR all worked fine without Modes and with UDMA 4, no freezes at the starting logos
and no stutter in the intro FMV, all fine.

As i tested the PAL-French version you can remove the Untested comment from here:

https://github.com/ifcaro/Open-PS2-Loader/pull/173/commits/44bf253ce8f9222608d8f8104a22a80441aeb52f

I don't have and i don't found the PAL-German (SLES-50402) and the NTSC-J versions,
if someone have any of this two versions and can test them would be great, thank you.

All tested with r1250 in the internal HDD.

Best regards.

 

[sp193]

Noted. Some adjustment has to be made to factor in the prefix option, which is user-configurable.

I think the new commits should address this. https://www.sendspace.com/file/ik8tr2

I don't see what's preventing files on smb: from being booted, but I cannot attend to it now.

Both HDD and SMB stops glitching with Mode 1 if transfer is limited to around 900 kB/s.

I added some code that will break into the debugger if libcdvd gets double-booked (i.e. due to missing a call to sceCdSync() before sceCdread()), and nothing unusual happened. So it might be a fault within the rendering part of the game.

As i tested the PAL-French version you can remove the Untested comment from here:

Thank for your help. I have removed those comments, except for the NTSC-J version.
I think the only release that has a risk of not being compatible is the NTSC-J version because it was released nearly a year later, which gives the developers an opportunity to change more things.

 

[Zarper]

I added some code that will break into the debugger if libcdvd gets double-booked (i.e. due to missing a call to sceCdSync() before sceCdread()), and nothing unusual happened. So it might be a fault within the rendering part of the game.

If the games rendering is at fault, shouldn't that show up on the original disc and ESR as well? And why does limiting the transfer speed to such extreme proportions fix the issue?

Were you able to reproduce the glitch on your dev kit?

 

[Peppe90]

I don't know what is going on, but recently we have got almost different experience.
I can easily pass this screen, with mode 2, start race, etc.
However I'm using PAL game on PAL console.
Tested with OPL 1250 through SMB.

I tested MODE 2+6 with older versions and only one time (maybe it's a hit or miss?). I'll try it with OPL 1250 (maybe the new changes solved the problems?).

 

[Grahf]

If the games rendering is at fault, shouldn't that show up on the original disc and ESR as well? And why does limiting the transfer speed to such extreme proportions fix the issue?

Were you able to reproduce the glitch on your dev kit?

It's the timing. A CD game will be read very slowly not because of the reading speed per se, but because of all the mechanical crap involved with actually reading the disc. Since we don't have an accurate CDVD emulator, we can't reproduce the exact timing of it. However, limiting speed so much is giving the same results since we're basically replacing all the mechanical timing of a real CDVD by simply making OPL read data slower.

 

[Zarper]

It's the timing. A CD game will be read very slowly not because of the reading speed per se, but because of all the mechanical crap involved with actually reading the disc. Since we don't have an accurate CDVD emulator, we can't reproduce the exact timing of it. However, limiting speed so much is giving the same results since we're basically replacing all the mechanical timing of a real CDVD by simply making OPL read data slower.

I would consider that a timing issue, likely in some kind of thread or buffer creation/deletion. Not a rendering issue.

 

[TnA]

You both are likely correct on that... (but who knows)

Edit: That does not mean that it's the root of the issue... It could be a trigger again (IF there is such a kind of issue involved)...

 

[sp193]

If the games rendering is at fault, shouldn't that show up on the original disc and ESR as well? And why does limiting the transfer speed to such extreme proportions fix the issue?

It depends on the nature of the bug. As you can see, the combination of events that take place, allowed it to work.

Were you able to reproduce the glitch on your dev kit?

Yes, but nothing unusual was found. Not really surprising though, because it is a runtime bug.

I would consider that a timing issue, likely in some kind of thread or buffer creation/deletion. Not a rendering issue.

• This is a single-threaded game.
• Does not do dynamic buffer allocation (it always reads to the same addresses, mainly 0x01800000).
• Does not involve any custom IOP module, other than for sound playback. Not even for reading the sound file.
• Seemingly always changes every read command into a sync operation, so it always waits for reading to complete.
• Commands are queued. Seems to be LIFO-styled.
• While reading is done, the UI can be rendered.

It is somehow just rendering with the wrong data. Other than the possibility of a design flaw, I cannot tell if it has some cache coherency problem or is affected by a restriction of the EE/GS.

Why hasn't anybody suggested using mode 2 with this game? It is a single-threaded game, mode 2 could cause some lag during loading (which it doesn't always do anyway), but it will prevent any design flaw from affecting the transfer of textures from the media to VRAM.

 

[Grahf]

Why hasn't anybody suggested using mode 2 with this game? It is a single-threaded game, mode 2 could cause some lag during loading (which it doesn't always do anyway), but it will prevent any design flaw from affecting the transfer of textures from the media to VRAM.

Mode 2 was tried. It does nothing for this issue. Only limiting the speed to around 900 kB/s fixes it.

 

[sp193]

Mode 2 was tried. It does nothing for this issue. Only limiting the speed to around 900 kB/s fixes it.

Oh lol, I think I know why this happened. It's because calling sceCdRead() from the EE will always be asynchronous. We cannot really change how that RPC call works, short of patching the game.

So if you (or anyone) wants to see if the flaw is with the rendering half not waiting for reading to complete first, we can try this: https://www.sendspace.com/file/7gd5ot
I changed the parameter to sceCdSync() to 0, so it will always block from the first call to sceCdSync().

But even if it works, it does not mean it is a good idea for every device in OPL.

 

[jolek]

@Maxis you should try Ferrari Challenge - Trofeo Pirelli, both versions PAL (SLES_552.94) and NTSC (SLUS_217.80) should work now.
You can try OPL 1258 from here:
http://www.psx-place.com/threads/automated-daily-build-system-for-opl-wle-fceumm-ps2.19382/
or from here:
http://www.psx-place.com/threads/open-ps2-loader-official-beta-releases.21573/.

 

[Grahf]

So if you (or anyone) wants to see if the flaw is with the rendering half not waiting for reading to complete first, we can try this: https://www.sendspace.com/file/7gd5ot
I changed the parameter to sceCdSync() to 0, so it will always block from the first call to sceCdSync().

But even if it works, it does not mean it is a good idea for every device in OPL.

Isn't it actually better to just limit the speed to 900 kB/s for this game? Surely, such a change to sceCdSync will screw up many games.

 

[Zarper]

Oh lol, I think I know why this happened. It's because calling sceCdRead() from the EE will always be asynchronous. We cannot really change how that RPC call works, short of patching the game.

So if you (or anyone) wants to see if the flaw is with the rendering half not waiting for reading to complete first, we can try this: https://www.sendspace.com/file/7gd5ot
I changed the parameter to sceCdSync() to 0, so it will always block from the first call to sceCdSync().

But even if it works, it does not mean it is a good idea for every device in OPL.

Not sure if I need to do something else, but I tried that version with Mode 1 and 1+2 on HDD (Mode 1 just to make testing quicker) and the game still glitches.

Btw, if commands are queued LIFO, could commands possible come in too fast and mess with the order?

 

[sp193]

Isn't it actually better to just limit the speed to 900 kB/s for this game? Surely, such a change to sceCdSync will screw up many games.

It was a patch for this game, meant for just a test.

Not sure if I need to do something else, but I tried that version with Mode 1 and 1+2 on HDD (Mode 1 just to make testing quicker) and the game still glitches.

Thank you. This probably means that the problem is elsewhere. Since the main thread will always be blocked once sceCdSync() is called, it becomes impossible for the main thread to miss any data read, due to delays in device input etc.

Unless it is possible for the game to try to upload before reading is completed, but I think it should have been easier to glitch than this and would have affected faster devices instead of... slightly slow ones. This possibility (unfortunately) still exists because I haven't seen how the game uploads textures, so I cannot tell if it does wait for its own command queue to be complete or not, but I have this feeling that is not the problem because you're getting away with slowing it down to some absurd speed (and the game seemed faultless from USB).

I wonder what kind of bug this game really has...

Btw, if commands are queued LIFO, could commands possible come in too fast and mess with the order?

Since it's single-threaded, it cannot choke itself. It would have been a case of simple is best and least error-prone, but somehow, something is not done right.