PS2 Open PS2 Loader v1.1.0

[ted209]

Also unfortunately from I remember "conf_apps.cfg" need to be copied into "mc?:/OPL".
I cannot be on mass, hdd0, smb, because it might not be loaded from other devices.

What path you used to make a shortcut to apps on SMB (smb:/APPS/)?

Yes, conf_apps.cnf does have to be in mc?:/OPL and yes, my shortcut points to smb:/APPS/boot.elf

It definitely finds the elf because if the path is wrong then it raises an error. I will try an older version of OPL to see if it's the recent changes that broke it.

 

[ted209]

Does it ever worked for SMB via conf_apps.cfg?

I just tried it with build 1196 (from Oct 18) and it works fine, so this is a bug that relates to the recent improvements.

EDIT: a workaround to this would be to change the new functionality to allow for paths outside of the APPS folder, eg allowing title.cfg to be:

title=Power Shovel
boot=smb:/POPS/SB.SLUS_013.43.Power Shovel.ELF​

or

title=Power Shovel
boot=/POPS/SB.SLUS_013.43.Power Shovel.ELF​

The second would be better as it's independent of the device.

 

[sp193]

Thanks, but the problem is that something as basic as IOP reboots should normally not fail. Since it cannot be replicated on development hardware and there are no obvious reasons for that to happen, I cannot do anything about this.

As for VMC, nothing was changed for months, maybe years.

As for the multiplayer side of Splinter Cell: Double Agent: it appears that there is a second part of IGR that uses the SockParam parameter, without any check on whether SockParam can be used...

Regarding the location of translations: it currently does not support other locations, other than memory card.

I think I found a bug with the apps menu.

I can get ulaunchelf to load by either:
1. Setting up the folder structure and title.cfg (this works on USB and SMB)
2. Making a conf_apps.cfg file on the memory card that points to the ulaunchelf file (works on USB but not on SMB)

What did you enter for the path? If it begins with smb:/, try using smb0:/ instead.
There probably needs to be some adjustment to allow the unit number to be omitted.

The problem is that I need to use the old conf_apps.cfg file for popstarter, because the elf needs to be in the pops folder (it doesn't work if you put it in an apps folder with title.cfg).

@krHACKen: sorry to bother you, but I must ask if this is an actual limitation with POPStarter. Is there no way to move its ELF someplace else?

If users can put the POPStarter ELF in the APPS directory, then there would be perhaps no need for the ps2-home mod anymore.

 

[Peppe90]

If users can put the POPStarter ELF in the APPS directory, then there would be perhaps no need for the ps2-home mod anymore.

IMHO, the Ps2-Home mod would still be good, 'cause with it you don't have to made the renamed POPStarter.elf for each game.
It's much more comfortable when upgrading or when testing different POPStarter versions (you just have to replace the POPStarter.elf file).

 

[jolek]

As for VMC, nothing was changed for months, maybe years.

I remember that recently (OPL 1200) at least @Algol have got trouble with GT3:
http://www.psx-place.com/threads/open-ps2-loader-v0-9-3.13415/page-11#post-145819.

VMC was created, game progress was saved, but after restart or power off console there was a problem with VMC.
I mean when user want to load it progress, there was no data to load.

 

[krHACKen]

The problem is that I need to use the old conf_apps.cfg file for popstarter, because the elf needs to be in the pops folder (it doesn't work if you put it in an apps folder with title.cfg).

@krHACKen: sorry to bother you, but I must ask if this is an actual limitation with POPStarter. Is there no way to move its ELF someplace else?

If users can put the POPStarter ELF in the APPS directory, then there would be perhaps no need for the ps2-home mod anymore.

I'm clueless...
- The renamed POPStarter ELF can be put anywhere, there's no limitation. If the ELF was properly renamed and it doesn't work, then it's surely due to yet another bug in the argument parser (in POPStarter). Patching the ELF for it to run with the debug texts enabled would confirm that.
- wLE_kHn wants /POPS/POPSTARTER.ELF, internal HDD and USB only. No SMB support.
- I've no idea how PS2-Home's OPL deals with the non-renamed POPSTARTER.ELF... I do know about "POOF" for sure, and don't want to be aware of anything else regarding that place and their OPL fork.

 

[ted209]

- The renamed POPStarter ELF can be put anywhere, there's no limitation.

I've just tried this and you're absolutely right. Popstarter works with the elf in any directory as long as the VCD is in the POPS folder.

Sorry for the confusion. My issue is solved, (although the conf_apps.cfg bug remains).

 

[Peppe90]

I remember that recently (OPL 1200) at least @Algol have got trouble with GT3:
http://www.psx-place.com/threads/open-ps2-loader-v0-9-3.13415/page-11#post-145819.

VMC was created, game progress was saved, but after restart or power off console there was a problem with VMC.
I mean when user want to load it progress, there was no data to load.

Here: https://www.reboot.ms/forum/threads...-emulatore-interno.1712/page-10?_params=Array

@bobbyso have problems with VMC using NFS Underground 2 (corrupted savedata) and Baldur's Gate 1 (corrupted VMC).

He said that once OPL failed to create a 64mb VMC and said that saving to VMC is slow (4 times slower than saving on MC).
He's using a Gamstar NA. I thought it could be something related to the NA not perfectly fitting into the Ps2 (is a common issue), but I'm not sure…

He's using Ps2-Home Daily Builds.

 

[sp193]

Phasing out SMSTCPIP (?)

As of yesterday, I have attempted to backport further patches from the LWIP upstream. However, not only did I encounter problems with making some patches fit well, the risk of breaking it is quite great and it seems like the root of the stability bug wasn't improved by any of these changes.

Here were the patches I backported (or wrote):

• SMSTCPIP: backported patch for bug #28716 (2010-01-23) - select() returns 0 after waiting for less than 1 ms.
• SMSTCPIP: backported patch for bug #23240 (2009-07-09) - recv_udp increases counters for available receives before netbuf is actually posted.
• SMSTCPIP: backported patch for bug #26405 (2009-05-05): Prematurely released semaphore causes lwip_select() to crash.
• SMSTCPIP: Backported patch for bug #21698 (2007-12-21) - netconn->recv_avail is not protected.
• SMSTCPIP backported patch (2007/03/28) by Frédéric Bernon: netbuf_ref doesn't check its internal pbuf_alloc call result and can cause a crash.
• SMSTCPIP backported patch (2007/03/26) by Frédéric Bernon - api_lib.c (from Dmitry Potapov) : patch for netconn_write(), fixes a possible race condition which cause to send some garbage.
• SMSTCPIP: backported patch (2007-03-21) by Frédéric Bernon: integrate sys_mbox_fetch(conn->mbox, NULL) calls from api_lib.c to tcpip.c's tcpip_apimsg().
  
• SMSTCPIP: removed MEMP_API_MSG as it is no longer needed.
  
• SMSTCPIP: do not use op-completion signalling if TCPIP core locking is used, as it is redundant. This is to merge the new feature with the old design.
• SMSTCPIP: backported fix Fix for Nagle algorithm as reported by Bob Grice (2006-10-10).

The patch by Frédéric Bernon on 2007-03-21 did not integrate well and is not fully working when TCPIP core locking is disabled. I think it is because the API messages go out of scope once the callee signals operation completion, which is caused by our tcpip thread signaling mechanism being older.
Worst still, I think it's even more unstable now. I never played any games with it, but I got a lot of problems with using DECI2 over SMSTCPIP, due to its bugs.

Since the TCP connection seems to get stuck while ICMP pings can be responded to, perhaps the TCP state machine got stuck. I have already backported all the fixes for the sockets layer, for as far as I can see.

Since there are too many changes, I'm starting to (once again) lean towards aborting any progress on this and phasing out SMSTCPIP. SMSTCPIP might have been based on LWIP v0.7.x, with some fixes backported over the years. LWIP is now at v2.1.2, while the PS2SDK is at v2.0.0.
I know I wrote before that the new stack is larger than SMSTCPIP, so I am hoping to shrink its size by cutting out some functions we don't use. Yes, this will make it differ from the standard LWIP code base, but that's also what SMSTCPIP is anyway - a custom version of LWIP.

IMHO, the Ps2-Home mod would still be good, 'cause with it you don't have to made the renamed POPStarter.elf for each game.

Then don't rename it. You're free to name it anything you want.
It's just that the VCDs must be in the same directory as POPStarter is.

It's much more comfortable when upgrading or when testing different POPStarter versions (you just have to replace the POPStarter.elf file).

The only benefit I can think of, is that you will only need 1 copy of POPStarter for all games. But this is the effect of giving each app its own directory.

I remember that recently (OPL 1200) at least @Algol have got trouble with GT3:

Here: https://www.reboot.ms/forum/threads...-emulatore-interno.1712/page-10?_params=Array

@bobbyso have problems with VMC using NFS Underground 2 (corrupted savedata) and Baldur's Gate 1 (corrupted VMC).

He said that once OPL failed to create a 64mb VMC and said that saving to VMC is slow (4 times slower than saving on MC).
He's using a Gamstar NA. I thought it could be something related to the NA not perfectly fitting into the Ps2 (is a common issue), but I'm not sure…

Yes, I know that people have been finding problems. But the thing is that nothing was changed there for years. At least, not by me anyway.
There are too many things for me to handle, which is why I am refraining from touching on VMC.

OPL didn't have all code contributed by 1 person. In this case, VMC was contributed by polo35. So now that they're all gone, there are too many parts with problems that need to be addressed by one person.

The renamed POPStarter ELF can be put anywhere, there's no limitation.

Okay, thank you!

Sorry for the confusion. My issue is solved, (although the conf_apps.cfg bug remains).

So did renaming the device name to smb0 not help? Or did you not try it out?
I'll push a patch sooner or later, just that now I am also trying to replace SMSTCPIP, so that we can bury it with all its old problems.

 

[Grahf]

To be honest, I think people expect too much from OPL at this point. It should be a simple and highly compatible game loader, but it's like in those old jokes about people wanting the toaster to make coffee and scrambled eggs as well.

There's a ton of stuff added on top of the core functionality by now and it only fuels the bugfest, whereas the main objectives get unprioritized.

We should have had a public release for 0.9.4 a long time ago, ensuring better compatibility and performance, but it's so hard to do it when all the extra features keep causing more and more issues.

 

[jolek]

Phasing out SMSTCPIP (?)

As of yesterday, I have attempted to backport further patches from the LWIP upstream. However, not only did I encounter problems with making some patches fit well, the risk of breaking it is quite great and it seems like the root of the stability bug wasn't improved by any of these changes...

Thanks for another part of fixes\patches.

As for VMC, well...
Many games works with this feature very well, at least we can use it for tests.

 

[Algol]

Hello.

Le fait que OPL ne nous permettent plus de gérer convenablement les VMC via ETH avec le jeu "GT3" (Gran Turismo 3) nous (mon club local et moi-même) a obligé de stopper les tests que nous réalisions depuis cette époque.
C'est une preuve d'instabilité certaine même si dans d'autres cas il y a des améliorations.

Les VMC sont primordiales pour ne pas trop "massacrer" les vrais "Memory Card", l'usage est assez simple et elles sont "portables" d'une interface à l'autre (Ethernet, USB, Disque Dur).


In English via Google :

The fact that OPL no longer allows us to properly manage the VMC via ETH with the game "GT3" (Gran Turismo 3) we (my local club and myself) has forced to stop the tests that we realized since that time.
This is proof of certain instability even if in other cases there are improvements.
The VMC are essential to not "massacre" the real "Memory Card", the use is quite simple and they are "portable" from one interface to another (Ethernet, USB, HDD).

Good luck.

 

[Peppe90]

Then don't rename it. You're free to name it anything you want.
It's just that the VCDs must be in the same directory as POPStarter is.

The only benefit I can think of, is that you will only need 1 copy of POPStarter for all games. But this is the effect of giving each app its own directory.

I used to play Ps1 games as APPS. It's a good way, but you need (from usb i.e.) XX.gamesname.elf for each game. And when you upgrade POPStarter, you have to remade all XX.gamesname.elf.

Ps2-Home has the VCD launcher (similar to uLE_kHn I think). So you just need to replace the POPstarter.elf and you're done.

 

[ted209]

So did renaming the device name to smb0 not help? Or did you not try it out?

I just tried this now - yes, using smb0 allows me to use opl_apps.cfg again. Thank you!

 

[sp193]

Harvest Moon: A Wonderful Life Special Edition

While the game could not be debugged as the glitch never seems to occur once DECI2 communications is established, I could dump memory after the glitch has taken hold by connecting to DECI2 later on (with OPL's built-in copy of RDB).
Since I have a dump of my PS2's kernel and have been disassembling it, I could study the kernel's Thread Control Blocks (TCBs) to know the state of all threads.

This game seems to create alot of threads. When the game gets stuck, all the threads are either suspended or waiting.
What seems to be happening is thread 16 trying to wake up the main thread. However, this might be failing because the game also has additional checks around WakeupThread - to prevent a thread from waking up another thread, if the thread to be woken up is not in a Wait state. So if the main thread has not slept yet, the main thread will enter a state of eternal sleep once it does sleep because thread 16 is prohibited from waking it up.
Thread 16 will not make further attempts to wake up the main thread as it will also sleep, regardless of whether the main thread was successfully woken up or not.

Disabling the extra checks seem to make the glitch go away, but I don't know why they added extra code like that. By design, calling WakeupThread on a thread that is not sleeping will increase the wakeupCount variable of the thread, which will cause it to inhibit a number of calls to SleepThread() by that amount (which I think is fair - if the thread has to be woken up, it should be).

The mistake may be made in various places, but seems to only affect the game's initial loading screen.

   ...
   lw     v1, $0000(s1)     # v1=isMainThreadSleeping
   addiu     a0, zero, $0001
   sd     s0, $0030(sp)
   bne     v1, a0, $0011b6e0   # If main thread is not sleeping, do nothing
   sd     ra, $0040(sp)
   lui     v0, $004a
   daddu     a1, sp, zero
   addiu     s0, v0, $16a8
   jal     $00444060     # jal ReferThreadStatus
   lw     a0, $0000(s0)     # a0=mainThreadId
   lw     v1, $0000(sp)     # Get main thread status
   addiu     v0, zero, $0004     # THS_WAIT
   beq     v1, v0, $0011b6c8   # If main thread is not in THS_WAIT state
   addiu     a0, zero, $000c     # THS_WAITSUSPEND
   bnel     v1, a0, $0011b6e4   # nor in THS_WAITSUSPEND state,
   ld     s0, $0030(sp)     # Don't wake up the main thread.
__0011b6c8:
   lw     a0, $0000(s0)     # Main thread ID
   jal     $00444090     # jal WakeupThread
   nop
   lw     v1, $0000(s0)     # Check whether it was successfully woken up.
   beql     v0, v1, $0011b6e0
   sw     zero, $0000(s1) # Indicate that the main thread was woken up.
   ...

Since I never played Harvest Moon, I don't know whether this change would change the game's functionality.

Originally, I was hoping that I just needed to change the thread priorities. But giving the main thread a higher priority than thread 16 didn't seem to help.

For now, the patch will only apply to the US release (SLUS-21117): https://www.sendspace.com/file/za9i05
There seems to be a lot of Japanese releases. I doubt we'll successfully find owners of all of them to borrow the ELFs from them, so a generic patch might have to be written.

 

[Peppe90]

Harvest Moon: A Wonderful Life Special Edition

While the game could not be debugged as the glitch never seems to occur once DECI2 communications is established, I could dump memory after the glitch has taken hold by connecting to DECI2 later on (with OPL's built-in copy of RDB).
Since I have a dump of my PS2's kernel and have been disassembling it, I could study the kernel's Thread Control Blocks (TCBs) to know the state of all threads.

This game seems to create alot of threads. When the game gets stuck, all the threads are either suspended or waiting.
What seems to be happening is thread 16 trying to wake up the main thread. However, this might be failing because the game also has additional checks around WakeupThread - to prevent a thread from waking up another thread, if the thread to be woken up is not in a Wait state. So if the main thread has not slept yet, the main thread will enter a state of eternal sleep once it does sleep because thread 16 is prohibited from waking it up.
Thread 16 will not make further attempts to wake up the main thread as it will also sleep, regardless of whether the main thread was successfully woken up or not.

Disabling the extra checks seem to make the glitch go away, but I don't know why they added extra code like that. By design, calling WakeupThread on a thread that is not sleeping will increase the wakeupCount variable of the thread, which will cause it to inhibit a number of calls to SleepThread() by that amount (which I think is fair - if the thread has to be woken up, it should be).

Since I never played Harvest Moon, I don't know whether this change would change the game's functionality.

Originally, I was hoping that I just needed to change the thread priorities. But giving the main thread a higher priority than thread 16 didn't seem to help.

For now, the patch will only apply to the US release (SLUS-21117): https://www.sendspace.com/file/za9i05
There seems to be a lot of Japanese releases. I doubt we'll successfully find owners of all of them to borrow the ELFs from them, so a generic patch might have to be written.

I never had problems with this game with every configuration so I can just verify if it still works.

Let's see if it solve @Tupakaveli freeze

 

[jolek]

There seems to be a lot of Japanese releases. I doubt we'll successfully find owners of all of them to borrow the ELFs from them, so a generic patch might have to be written.

I've only found SLPS_732.22.
Can you point me to other versions?

I mean other JAP versions, not:
SLES_534.80,
SLUS_211.71.

 

[sp193]

I've only found SLPS_732.22.
Can you point me to other versions?

According to the PCSX2 compatibility page for this game, there are:

• SLUS-21171
• SLES-53480
• SLPS-25431
• SLPS-25421 (First Print Limited Edition)
• SLPS-73222 (PlayStation 2 the Best)

While it is possible that the same game was released for all Japanese releases, there is nothing that suggests it happened.

 

[jolek]

At least SLPS_732.22, SLES_534.80, SLUS_211.71, have the same version 1.02.

Unfortunately SLPS_254.31 release hasn't been added:
http://wiki.redump.org/index.php?title=Sony_Playstation_2_Asia_Missing_Dumps.

Probably also owner of SLPS_254.21 (First Print Limited Edition) will be very hard to find.

BTW: Thanks for adding more info.
I've also found:
https://gamefaqs.gamespot.com/ps2/924390-harvest-moon-a-wonderful-life-special-edition/data.

 

[Vedita BR]

Rev d062a18 fixed Twisted Metal - Black Online...