PS2 Open PS2 Loader v1.1.0

[unseen]

I normally use Time Splitters for Swap, to not waste DVDs

Back in the day, I did my first mcBoot card with the game Extermination using a DVD-RW.

 

[sp193]

I have found that our IGR implementation does not wipe user memory before booting the next ELF, which occasionally resulted in faulty behaviour.

I spent so long, wondering why it seemed like very large portions of the OPL GUI's memory was getting corrupted after IGR, seemingly getting overwritten by other regions of itself. It seemed to be caused by (leftover) old code from the game getting called by OPL's code/old data causing the new code to misbehave. @_@

The pull request hasn't been merged yet, so I added the new fixes there. Here is something for you to play with, while waiting.

Do you know, why the thread-IDs change in the first place? That might be interesting.

Threads live (CreateThread) and die (DeleteThread), that is why. It's the normal lifecycle of threads.

For this bug in particular, the main thread got changed, which was why the main thread's ID changed. It is possible to keep the same main thread alive by using it to call ExecPS2(), but we cannot do that easily because the main thread is not in our control. But there is nothing in the documentation that suggested that the main thread's ID will always be 1.

FMCB/FHDB MIGHT have an issue which is related to one of those or triggered via one (or a combination) of those!

FMCB/FHDB does not change the way the PS2's kernel works. Only OPL does that.

@sp193: I have some questions regarding the Ferrari Challenge tests you did...

1. Is a second IGR and 3rd game-boot possible (not sure if it freezes quite in the beginning) and are the Thread-IDs the same like after the first IGR and the 2nd game-boot?
2. If NOT, does it ever show the same IDs for the 2 tests? If yes, I suppose this 'Thread-ID-change'-issue possibly is not caused by OPL.
3. If it freezes too early, I'd be interested if you could try to IGR a few times out of other games and then try Ferrari Challenge again. Are the Thread-IDs like they were in your earlier test before or after the IGR or again different?

The thread IDs will always change, as long as you run any software that creates and deletes threads. Here, it's because IGR will cause the main thread to change because we have no power over the original main thread, so we make the IGR thread the main thread.

There is only one thread that has a fixed ID, which is the idle thread (ID 0).

There's no way (officially) to switch to another game without going through the HW Reset. Even with games with official HDD support (like jap versions of FFX), there's no way to exit a game without resetting the console.

Actually, the system exists. It's just that (all?) disc-based games do not allow you to return to the browser.
What we're doing for IGR, is to wrench control from the game and kill it.

Most of the world did not get to experience the PSBB, but the DLCs should have that function. I know that POPS certainly did.

 

[Peppe90]

THAT is absolutely NOT true!

Take a look at here:

I mentioned the double-time-swap before and thought you'd do it that way...

lol, you do not know who you're talking to, Swap Magic is my second name

One thing is to directly launch cogswap (58kb) another is to directly launch OPL (or even Ulaunchelf)... You told me you don't want to use cogswap.

It doesn't need to be directly IGR-related or has to leave some code back behind, like I already said... IGR could merely be a trigger! Please don't 'jump to conclusions' too fast... I had seen that 'somewhere' before (quite recently). ^^

This doesn't prove YET, that IGR's code itself is at fault (even tho' it might seem likely)! But obviously I made a thread to explore the VARIOUS IGR-related issues (regardless if IGR is directly at fault or just a trigger), so I think that's quite obvious that I think the IGR-Tests might help us with various issues...

Sorry, maybe I did not say it clear enough. I agree, the IGR is not the problem, simply it can't completely erase the Ps2 memory/make it as it would be on his first boot, that's all. If the IGR would do that, pratically you'd have a cold boot after every IGR

No... Just no... That does NOT prove (or 'letting us know') that any of the additional code we introduce is left behind!

That solely proves that IGR could trigger the issue and in FC's case, it has a different Thread-IDs, which causes the issues (or more specifically the hard-coded Thread-IDs the developer wants to call/'speek to' from other threads are not working, because the IDs changed after an IGR...).

That does still not prove that IGR itself is directly at fault, or that it leaves some code in RAM, but the 'state' of the console certainly changes...

Yes I think I explained better just above.

I wonder if the same happens, if someone starts wLE from FMCB, accesses the HDD and then starts OPL and then the game!

Then the culprit/error is most likely to be searched in OPL itself and how it handles the current 'state' the PS2 is running in.

I start games this way a lot of times, what difference I should notice??

 

[Tupakaveli]

Wasn't there also some issue with VMC if you IGR back to OPL or does this solve that as well?

 

[El_Patas]

Fix for Ferrari Challenge: Trofeo Pirelli (SLES-55294)

The game has no direct issues with OPL itself, but will hang after the memory card check screen, only if IGR was used before.
The main thread gets stuck in Sleep state, due to the developers hardcoding the thread ID of the main thread.

Thread list, once the game hangs:

dsedb R> dt
tid prio  pc  sp  status cause sid wakeup count function
  0 128 00081fc8 00000000  Run  0  7211
 10  5 004e1208 07ffebc0  Wait Sleep  0  4163
 15  0 004e1328 00671160  Wait  Sema  2  0  1
 16  2 004e1208 00646e40  Wait Sleep  0  6365
 17  2 004e1328 0064f370  Wait  Sema  12  0  2
 18  0 004e1208 0066e950  Wait Sleep  0  1
 19 127 0008e138 000925c0  Wait Sleep  0  1

Thread 10 is the main thread, while thread 19 is the IGR thread.

Compared to how things were when the game was run the first time:

dsedb R> dt
tid prio  pc  sp  status cause sid wakeup count function
  0 128 00081fc8 00000000  Ready  0  1189
  1  5 004e1854 07ffeaf0  Run  0  1200
  6  0 004e1328 00671160  Wait  Sema  2  0  1
  7  2 004e1208 00646e40  Wait Sleep  0  169
  8  2 004e1328 0064f370  Wait  Sema  12  0  1
  9  0 004e1208 0066e950  Wait Sleep  0  1
 10 127 0008e138 000925c0  Wait Sleep  0  1

Here, thread 1 is the main thread and thread 10 is the IGR thread. Whenever we invoke IGR, the IGR thread becomes the main thread.

All threads are equal, but the developer hardcoded the thread ID of the main thread for the argument to WakeupThread():

dsedb R> di 0x12fcc4
  0x0012fcc4: 0x0c138484  jal  WakeupThread
  0x0012fcc8| 0x24040001  li  $a0,0x01

Since the main thread is no longer thread ID 1 during the subsequent runs, the main thread cannot be woken up.

@sp193, i tested the PAL version with the latest r1236 and now the game after an
IGR pass the memory check in the loading screen.

Thank you very much for the work, great

Then i checked the NTSC-U version (SLUS-21780) which i not tested never before, and i got
the surprise that the IGR not works with this version, (tried with the previous r1229 and
the r1236), when i press the IGR i obtain a "without signal " message on my TV.

Best regards.

 

[Peppe90]

I have found that our IGR implementation does not wipe user memory before booting the next ELF, which occasionally resulted in faulty behaviour.

I spent so long, wondering why it seemed like very large portions of the OPL GUI's memory was getting corrupted after IGR, seemingly getting overwritten by other regions of itself. It seemed to be caused by (leftover) old code from the game getting called by OPL's code/old data causing the new code to misbehave. @_@

The pull request hasn't been merged yet, so I added the new fixes there. Here is something for you to play with, while waiting.

Tried the build from your link. It seems that something changed for the better, this is what I done:

- I booted OPL from your link, started Ace Combat, then done a IGR
- the IGR path was set to OPNPS2LD-GAMELIST I had into the MC
- OPNPS2LD-GAMELIST succeeded to load the list (correctly reading games.bin file without going into the loading loop).

Btw "after IGR problems" remain for the games.
Ferrari Challenge (I have the USA version) still freeze at the second loading time rebooting it after a IGR it's been performed.

@El_Patas OPL r1236 you tried is the the one @sp193 linked HERE, right?? So we tested the same version.

Could you try another time with Ferrari Challenge TP (USA) if for you this behavior is stable?? I've IGResetted from this game thousands of times in the last years (for testing purposes) and it happened only one time to lost the video signal when IGResetting.

Normally it just IGR fine (to OPL or any other path) either if it freezed or not.

Situation is unchanged for Shawn Palmer's Pro snowborder too:

I checked "Shaun Palmer's Pro Snowboarder", unfortunately the situation is unchanged. I explain for who didn't know this game:

- no need of any MODEs
- at first boot it just works with any DMA, but after IGR the game will have problems at higher DMA.

i.e. I can boot the game in UDMA 4 at first, all is perfect, but after IGR the game will freeze just before appearing the starting logos (after the MC check) and there are high chances to freeze with UDMA 3 too.
With UDMA 2 it never freeze but the intro FMV have some stutter (both video and audio), the lower the DMA the less will stutter. Indeed I had the game set with MDMA0, so the stutter doesn't happen even if booting the game after an IGR.

I repeat, at every first start the game is perfect (intro FMV too) with every DMA (UDMA 4 too. I've set it so now, 'cause it pratically eliminate the loading time).

So it seems to confirm that after a IGR something still remains in memory causing problems to some games.

​

 

[sp193]

Then i checked the NTSC-U version (SLUS-21780) which i not tested never before, and i got
the surprise that the IGR not works with this version, (tried with the previous r1229 and
the r1236), when i press the IGR i obtain a "without signal " message on my TV.

Btw "after IGR problems" remain for the games.
Ferrari Challenge (I have the USA version) still freeze at the second loading time rebooting it after a IGR it's been performed.

Thank you. The patch was not made for the NTSC-U/C version because I didn't realize there was one. I have extended the patch to support the NTSC-U/C version, but I am trying to complete other fixes first before pushing the commits.

Tried the build from your link. It seems that something changed for the better, this is what I done:

- I booted OPL from your link, started Ace Combat, then done a IGR
- the IGR path was set to OPNPS2LD-GAMELIST I had into the MC
- OPNPS2LD-GAMELIST succeeded to load the list (correctly reading games.bin file without going into the loading loop).

I see, thanks.

Situation is unchanged for Shawn Palmer's Pro snowborder too:

I looked at the NTSC-U/C version, SLUS-20199. The game's MPEG video playback might have been designed after the Sony mpegstr sample, which uses a "default thread" for switching between threads.
However, instead of changing the main thread's priority, the developers tried to use the main thread's priority for the other threads, but incorrectly used the main thread's ID instead.
During a clean boot of the PS2, this works okay because the main thread's ID is equal to the priority, of priority 1.

So after the thread IDs change (due to running something before the game), the mistake causes this to happen:

dsedb S> dt
tid prio  pc  sp  status cause sid wakeup count function
  0 128 00081fd0 00000000  Ready  0  4027
  7  1 00138f24 01fff730  Run  0  1217 <_start>
 16  0 0010caa8 002e8ff0  Wait  Sema  2  0  1 <topThread>
 17 127 0008e1a8 00092640  Wait Sleep  0  1
 18  7 0010c918 002f4700  Ready  0  79 <defMain>
 19  7 001094b4 01206170  Ready  0  163 <videoDecMain>

The default (defMain) and video decoder main (videoDecMain) threads no longer share the same priority as the main thread (_start)! And so the main thread busy-loops over the other 2 threads, causing a hang.

Does anybody have the European and Japanese versions?
The PCSX2 page suggests that there were 3 PAL releases, but are the three of them similar? https://wiki.pcsx2.net/Shaun_Palmer's_Pro_Snowboarder

I just need the boot file (e.g. SLES_504.00). So if somebody has the files from these games, I can update the patch to support them.

 

[Peppe90]

I looked at the NTSC-U/C version, SLUS-20199. The game's MPEG video playback might have been designed after the Sony mpegstr sample, which uses a "default thread" for switching between threads.
However, instead of changing the main thread's priority, the developers tried to use the main thread's priority for the other threads, but incorrectly used the main thread's ID instead.
During a clean boot of the PS2, this works okay because the main thread's ID is equal to the priority, of priority 1.

So after the thread IDs change (due to running something before the game), the mistake causes this to happen:

dsedb S> dt
tid prio  pc  sp  status cause sid wakeup count function
  0 128 00081fd0 00000000  Ready  0  4027
  7  1 00138f24 01fff730  Run  0  1217 <_start>
 16  0 0010caa8 002e8ff0  Wait  Sema  2  0  1 <topThread>
 17 127 0008e1a8 00092640  Wait Sleep  0  1
 18  7 0010c918 002f4700  Ready  0  79 <defMain>
 19  7 001094b4 01206170  Ready  0  163 <videoDecMain>

The default (defMain) and video decoder main (videoDecMain) threads no longer share the same priority as the main thread (_start)! And so the main thread busy-loops over the other 2 threads, causing a hang.

Does anybody have the European and Japanese versions?
The PCSX2 page suggests that there were 3 PAL releases, but are the three of them similar? https://wiki.pcsx2.net/Shaun_Palmer's_Pro_Snowboarder

I just need the boot file (e.g. SLES_504.00). So if somebody has the files from these games, I can update the patch to support them.

I see, thank you for all the infos and efforts
Anyway, the different behavior depending on the DMA speed is caused by the same issue??

Setting UDMA 2 (or below) the game won't freeze after all IGRs you want (just the intro will stutter at higher DMA, but in MDMA 0 it wouldn's stutter at all).

I too have the USA version of this game.

Another game I'm testing is Air Combat the Unsung War. Like State of Emergency It's one of those games that have problems since the r730.
It seems to freeze at mission 6 and 9 (and maybe Others), I can't confirm yet (I completed just a mission). Everything works fine so far, aside one thing: the briefings background music is missing.

 

[sp193]

I see, thank you for all the infos and efforts
Anyway, the different behavior depending on the DMA speed is caused by the same issue??

Setting UDMA 2 (or below) the game won't freeze after all IGRs you want

It should be that same problem. The immediate issue when it hangs, is that the audio input ring buffer is full, but no playback can take place because the main thread is preventing the video decoding thread from running (it is not clear to me either, but perhaps it cannot continue playing audio because the video stream cannot be played).

So when it takes a while to read data, this glitch can be avoided. But in the first place, its thread-scheduling mechanism fails once the main thread's ID changes, due to the mistake that the developers made. If the game was played in the way it was designed (i.e. switch on PS2 and insert game disc), then it will always work correctly and the bug is not visible.

(just the intro will stutter at higher DMA, but in MDMA 0 it wouldn's stutter at all).

This might be due to thread starvation, which can happen if the game requests a lot of data. Does accurate reads not help?

I too have the USA version of this game.

I see. Then the patch will be applicable to you, once it is committed.

I'm looking for people who own the other releases because I need their boot executable files to adapt the patches to fit the other releases.

Another game I'm testing is Air Combat the Unsung War. Like State of Emergency It's one of those games that have problems since the r730.
It seems to freeze at mission 6 and 9 (and maybe Others), I can't confirm yet (I completed just a mission). Everything works fine so far, aside one thing: the briefings background music is missing.

I see, thanks. The lack of background music might be some other issue. Have you tried using accurate reads with this?

 

[El_Patas]

@El_Patas OPL r1236 you tried is the the one @sp193 linked HERE, right?? So we tested the same version.

Could you try another time with Ferrari Challenge TP (USA) if for you this behavior is stable?? I've IGResetted from this game thousands of times in the last years (for testing purposes) and it happened only one time to lost the video signal when IGResetting.

The r1236 which i used is the one of this stickied thread which points to resources and which have
a direct link to the download repository:

http://www.psx-place.com/threads/open-ps2-loader-official-beta-releases.21573/
I tried two times now again and this time the IGR worked, is strange, maybe yesterday
the without signal was casual, then i tried load the game a second consecutive time
and freezed like the PAL version after the fix.

Does anybody have the European and Japanese versions?
The PCSX2 page suggests that there were 3 PAL releases, but are the three of them similar? https://wiki.pcsx2.net/Shaun_Palmer's_Pro_Snowboarder

I just need the boot file (e.g. SLES_504.00). So if somebody has the files from these games, I can update the patch to support them.

The PAL versions they are different by languages, and the boot file are different
in their numbers, maybe each one needs the patch separately:

SLES-50400=English
SLES-50401=French
SLES-50402=German

I don't have the pal versions and they are hard to find, even the english one,
i hope someone have them, i'll try to search.

Best regards.

 

[jolek]

I hope @jolek can tell us the name of the ESR-Game, which didn't work with ESR if the PS2 wasn't coldbooted.

About the cold booting to OPL (that solved Half Life problem for @jolek) it seems a problem related to FHDB (indeed escluding it, the problem doesn't seems to occur). I use only FMCB and for me cold booting to OPL or not never make any difference.

I'm not sure if I explicit myself properly.

I was relying on post that I've made long ago at PSX-Scene.
From I remember cold boot seems to helps 2\3 games:

• Half-life to eliminate problems with sound\music:
  http://psx-scene.com/forums/f150/half-life-1-opl-buzzing-noise-vmc-issue-157007/#post1212349.
  
  
• The Fast and the Furious to pass this splash screen:
  
  
  
  
  
• Baldur's Gate: Dark Alliance 2:
  http://psx-scene.com/forums/f150/open-ps2-loader-bug-reports-65573/index43.html#post1205453.
  This problem was somehow fixed and now Baldur's Gate: Dark Alliance 2 is working fine through USB:
  http://psx-scene.com/forums/f150/open-ps2-loader-project-v0-9-3-a-62141/index801.html#post1218068.

Half-life works fine with SCPH-50004, 77004, 79003 when in OPL, PS2 logo will be enabled & shown,
no matter if I'm using FMCB or FHDB.

When I want to boot this game at cold boot -> E1 launch keys -> OPL (without PS2 logo) -> Half-life.
With FMCB I don't have any sound problems.
With FHDB buzzing sound & music seems to "appear" like I was normally launch OPL from FHDB menu.

I do not remember if cold boot -> fast boot (esr) helps these games, it was really long ago.

 

[Fanhais]

this the boot file of Shaun Palmer's Pro Snowboarder

 

[Peppe90]

It should be that same problem. The immediate issue when it hangs, is that the audio input ring buffer is full, but no playback can take place because the main thread is preventing the video decoding thread from running (it is not clear to me either, but perhaps it cannot continue playing audio because the video stream cannot be played).

So when it takes a while to read data, this glitch can be avoided. But in the first place, its thread-scheduling mechanism fails once the main thread's ID changes, due to the mistake that the developers made. If the game was played in the way it was designed (i.e. switch on PS2 and insert game disc), then it will always work correctly and the bug is not visible.

This might be due to thread starvation, which can happen if the game requests a lot of data.

​

Makes sense ​

Does accurate reads not help?

​

Yes, but it slowdown the loading times even more than MDMA 0. So it's better to use the latter.​

I'm looking for people who own the other releases because I need their boot executable files to adapt the patches to fit the other releases.

Probably this game has not been a best seller.

I see, thanks. The lack of background music might be some other issue. Have you tried using accurate reads with this?

Yes tried accurate thread and a lot of other MODEs/DMA combinations. Nothing solved so far.
With OPL revisions previous to r.733 the music is present. All work perfeclty without any particular setting.

 

[jolek]

@sp193 is there any chance to extend Fixed video mode confirmation message:
https://github.com/ifcaro/Open-PS2-Loader/pull/166/commits/eb95021f739ad692523639cd4c5d812a2333a198.

I mean, on some TV's this message might not be fully shown, it takes some time for them to adjust.
Currently there is ~5 sec to make a decision.
What about 10-15 sec?

 

[TnA]

this the boot file of Shaun Palmer's Pro Snowboarder

Please remove the file and rather PM him a link.

 

[Fanhais]

ok sorry

 

[Peppe90]

Someone knows if it's possible to make 2 different OPLs, to load 2 different cfgs?? I explain:

I'm using OPNPS2LD-GAMELIST-3 for Ps2 games. I have it in my MC (slot 2). It loads the cfg from my OPL folder in the same MC.

I have OPL_DB_1392 into my usb-hdd. I launch it with the E1 select launch key in case I want to use Ps1 games (that I have in my usb-hdd) with POPS.

Therefore, this is the problem: when I launch OPL_DB it loads the cfg from the MC, so it turn-on my iHDD (that I have on auto) and load my ps2 list. So I have the iHDD running for nothing and have to wait +20secs every time I IGR from a Ps1 game.

I know I can just set my iHDD to manual, but I like to have it on auto for autostarting my last Ps2 game, by this the question.

I tried making a OPL folder in my usb-hdd where the OPL_DB elf is, tried to copy my cfgs directly where OPL_DB is, but neither works, OPL_DB keep loading the cfg from my MC.

So, there's a way to make OPL_DB loading a cfg file from the usb-hdd or the priority will always be for the cfg into the MC??

 

[ShaolinAssassin]

I tried making a OPL folder in my usb-hdd where the OPL_DB elf is, tried to copy my cfgs directly where OPL_DB is, but neither works, OPL_DB keep loading the cfg from my MC.

So, there's a way to make OPL_DB loading a cfg file from the usb-hdd or the priority will always be for the cfg into the MC??

cfg from MC has always priority so no, not possible using standart builds. If you really wants that, maybe you could try some hex edit. Unpack 1 of the ELF version, and make it load cfg from mc?:/OPX instead of mc?:/OPL (I highlysuggest you to replace letters instead of inserting/deleting letters in the folder's name).

 

[Peppe90]

cfg from MC has always priority so no, not possible using standart builds. If you really wants that, maybe you could try some hex edit. Unpack 1 of the ELF version, and make it load cfg from mc?:/OPX instead of mc?:/OPL (I highlysuggest you to replace letters instead of inserting letters in the folder's name).

Perfect, Thank you very much

 

[sp193]

Yes, but it slowdown the loading times even more than MDMA 0. So it's better to use the latter.​

Okay, but I really hope that mode 1 will become the recommended solution. The transfer modes were not meant for attaining specific speeds or reading patterns.​

@sp193 is there any chance to extend Fixed video mode confirmation message:
https://github.com/ifcaro/Open-PS2-Loader/pull/166/commits/eb95021f739ad692523639cd4c5d812a2333a198.

I mean, on some TV's this message might not be fully shown, it takes some time for them to adjust.
Currently there is ~5 sec to make a decision.
What about 10-15 sec?

It was changed to 10s, as of yesterday.