PS2 Open PS2 Loader v1.1.0

[littlebalup]

Are you using a compatible/clone network adaptor? Due to changes in the design of DEV9 and ATAD, some clone/compatible adaptors that are not 100% compatible have stopped being compatible.

I'm using a genuine Sony network adaptor coupled with a DeLock SATA-IDE converter (Marvell 88SA8052) and a 500GB 2.5" HDD.
http://www.delock.de/produkte/F_661_SATA---eSATA---eSATAp_61702/merkmale.html

Did you set HDD mode to AUTO?

Yes

 

[sp193]

I'm using a genuine Sony network adaptor coupled with a DeLock SATA-IDE converter (Marvell 88SA8052) and a 500GB 2.5" HDD.
http://www.delock.de/produkte/F_661_SATA---eSATA---eSATAp_61702/merkmale.html

There is one more possibility.

There was a commit by belek666 that changed how OPL passes arguments to apps that are stored on the HDD unit.
Now it'll pass the full path (i.e. hdd0:+OPL:pfs:/<path to boot file>).

I'll tag @krHACKen here, in case he's interested in updating POPStarter to support this change, if that's the problem here.
If it's not the problem, then you'll have to ask the current OPL developer(s).

Yes

It has been a long time since I worked on OPL. Hmm, it appears that language files must be stored in the memory card...
Maybe I am wrong, but you can try putting the language file in mc:/OPL
The font can stay on the HDD unit, however.

 

[krHACKen]

Thank for reporting.

There is one more possibility.

There was a commit by belek666 that changed how OPL passes arguments to apps that are stored on the HDD unit.
Now it'll pass the full path (i.e. hdd0:+OPL:pfs:/<path to boot file>).

I'll tag @krHACKen here, in case he's interested in updating POPStarter to support this change, if that's the problem here.

Yes, that's POPStarter's fault. There is a missing parameter in its launch argument parser. It does not know what to do with the argument, and treats it like the entire argument is the elf file name lol (does not extract the ELF file name from the full path)...
So it tries to open VCD file "pfs#:/hdd0:+OPL:pfs:/GameName.elf.VCD" (with hdd0:__.POPS mounted) and quits to the OSD.

That's odd because it has no problem parsing the HDDOSD arg. The function is just a pile of mess and would have to be fully refactored asap.

 

[krHACKen]

https://github.com/ifcaro/Open-PS2-Loader/pull/59#issuecomment-321077438
Heh...

The current POPStarter prototype builds refuse to run from OPL, by design : I thought that it would be a good idea to block OPL from the protos, so the users don't put (and keep) those potentially unstable POPStarter ELFs in their fine gaming setups [OPL to be unblocked later, in the stable POPStarter releases]...

But now I see the questionable ELM crap jamming the pull reqs of the OPL official repository, I think it's better to leave OPL permanently blocked from POPStarter.

My choice is clear here : I prefer to make thousands of OPL users losing their PS1 arts unhappy, rather than to see the OPL contributors quitting the project because of the ELM/POPStarter annoyance.

 

[psydefx]

https://github.com/ifcaro/Open-PS2-Loader/pull/59#issuecomment-321077438
Heh...

The current POPStarter prototype builds refuse to run from OPL, by design : I thought that it would be a good idea to block OPL from the protos, so the users don't put (and keep) those potentially unstable POPStarter ELFs in their fine gaming setups [OPL to be unblocked later, in the stable POPStarter releases]...

But now I see the questionable ELM crap jamming the pull reqs of the OPL official repository, I think it's better to leave OPL permanently blocked from POPStarter.

My choice is clear here : I prefer to make thousands of OPL users losing their PS1 arts unhappy, rather than to see the OPL contributors quitting the project because of the ELM/POPStarter annoyance.

smh screw those people, you already provided a great modified ule that makes it super easy to launch popstarter games

 

[El_Patas]

https://github.com/ifcaro/Open-PS2-Loader/pull/59#issuecomment-321077438
Heh...

The current POPStarter prototype builds refuse to run from OPL, by design : I thought that it would be a good idea to block OPL from the protos, so the users don't put (and keep) those potentially unstable POPStarter ELFs in their fine gaming setups [OPL to be unblocked later, in the stable POPStarter releases]...

But now I see the questionable ELM crap jamming the pull reqs of the OPL official repository, I think it's better to leave OPL permanently blocked from POPStarter.

My choice is clear here : I prefer to make thousands of OPL users losing their PS1 arts unhappy, rather than to see the OPL contributors quitting the project because of the ELM/POPStarter annoyance.

Yes, please! leave OPL permanently and forever blocked from POPStarter, launching popstarter games
with the modified uLE is enough and easy of use.

Best regards.

 

[maneuuu]

thank you for your support!!it finally loads up my game list!!!!
only one problem to fix:how do i fix the graphics on opl?

Hello! I'm having the same problem 221: hdd not formatted. How did you solve it? I'm putting a 500gb HD. Ps2 just does not find the partitions of the games, but the hd it thinks with the free space!

 

[sp193]

That is only for HDPro/HDCombo. If you are not using that sort of product, you have a different problem.
If you are using HDPro, you need to use a new beta version of OPL because support for the HDPro was fixed recently.

 

[sp193]

SMSTCPIP with the TCPIP_CORE_LOCKING and TCPIP_CORE_LOCKING_INPUT features backported

SMSTCPIP with the TCPIP_CORE_LOCKING and TCPIP_CORE_LOCKING_INPUT features backported.
With these, it is possible to reduce some overhead for in-game network support by allowing the TCP/IP core functions to be called directly, but I expect it to be not so straightforward because our code is quite different from the latest version of LWIP.

In our case, TCPIP_CORE_LOCKING_INPUT does not allow ip_input to be called directly because we call from the interrupt context... but I think it still reduces some levels of abstraction.

Beta test: https://www.sendspace.com/file/3oqixd
Source code: https://github.com/sp193/Open-PS2-Loader/tree/lwip_core_locking

EDIT: It does not seem to work. I guess the new code allows for race conditions, but I cannot do anything about that at the moment.
Other people can try to solve this, while I get other (more important things) done.

 

[sp193]

And, I believe I have fixed it. I have also backported and fixed other stuff:

• (ingame-ATAD) fixed event flag creation (when debug is on)*.
• (ingame-SMSTCPIP) Fixed sys_sem_new to suspend interrupts before calling AllocSysMemory and updated sys_sem_new to use TH_SAPRI instead of a hardcoded literal.
• (ingame-SMSTCPIP) Fixed sys_mbox_post and sys_arch_mbox_fetch to signal sema only after resuming interrupts.
• (ingame-SMSTCPIP) Backported options for verifying checksums on various OSI layers, disabling them by default for the ingame driver.
• (SMSTCPIP) disabled DHCP_DOES_ARP_CHECK by default, as an IP address would be first required*.
• (ingame-SMSTCPIP) changed sys_arch_mbox_fetch to not dereference the message output pointer, if it is NULL.
• (ingame-SMSTCPIP) Back-ported TCPIP_CORE_LOCKING and TCPIP_CORE_LOCKING_INPUT.

*Done for correctness, but doesn't actually change anything.

SMB's performance has visibly improved for me.

Right now, I have not changed the TCP receive window size, even though ps2netbox has suggested it.
I remember why I didn't do it before: it is because our in-game driver will service the interrupt immediately, but will drop the frame if there is no available PBUF. So while it is true that our SMAP has 16KB of Rx FIFO space, we do not give LWIP 16KB of PBUF space.

Downloads/Links
OPL (2018/05/05) SMSTCPIP SMB beta: https://www.sendspace.com/file/etzf9e
Source code: https://github.com/sp193/Open-PS2-Loader/commits/lwip_core_locking

 

[sp193]

To follow up with what some users have mentioned about the use of the USBExtreme format (for USB & SMB modes) seemingly causing occasional problems with certain games, I did find a problem.

It happens if OPL is made to read across two parts. The offslsn variable is not updated correctly between the two reads, causing it to become negative.

Expected Result
Test case: LSN 0x7FFFF, sector count of 2.
1st pass: OPL will read LSN offset 0x7FFFF, 1 sector from part 0.
2nd pass: OPL will read LSN offset 0x00000, 1 sector from part 1.

Actual Result
Test case: LSN 0x7FFFF, sector count of 2.
1st pass: OPL will read LSN offset 0x7FFFF, 1 sector from part 0.
2nd pass: OPL will read LSN offset -1, 1 sector from part 1.

Related: issue on the OPL Github.

 

[jolek]

Is there a chance to add where setting will be saved, just like in FMCB\FHDB?

 

[jolek]

For a long, long time I was having a problem with Legacy of Kain - Soul Reaver 2.

Glitch was in USBExtreme format support.

The game crashes few second before intro movie ends (The solution was to skip movie).
Second crash was in air forge, when you go for the green crystal.

It was only affecting USB devices with sliced games images (.ul).

Recently SP193 made a patch for that support (USBExtreme).
I've tried OPL 1082 and everything is fine:

Thanks @sp193.

Latest BETA can be downloaded from here:
http://www.psx-place.com/threads/automated-daily-build-system-for-opl-wle.19017/.

EDIT: I was also having a problem with Baldur's Gate: Dark Alliance 2 SLES_521.88.
With OPL 0.9.3 at level "Firewind Manor I" game refuse to load cutscene, resulting a bug.

This happens only through USB. Through SMB mode cutscene work.
I have tried most compatibility mode with no luck.

Problem also has been fixed.

 

[sp193]

Glitch was in USBExtreme format support.

The game crashes few second before intro movie ends (The solution was to skip movie).
Second crash was in air forge, when you go for the green crystal.

It was only affecting USB devices with sliced games images (.ul).

Recently SP193 made a patch for that support (USBExtreme).

It affects SMB mode too. Just that perhaps more people use the USBExtreme format for USB devices, rather than SMB.

Related patch: https://github.com/ifcaro/Open-PS2-...3326a29#diff-4eb7c00e05c9ee1995030e7fa270fe6d
The 1 line ruins things under specific conditions.

 

[jolek]

It affects SMB mode too. Just that perhaps more people use the USBExtreme format for USB devices, rather than SMB.

I forgot about it, because mostly for PC HDD I use NTFS or EXT4 file system.
That files systems supports single files larger than 4 GB.
Although, thanks once again for a fix.

 

[jolek]

I've been testing OPL 1086 and I've notice that some FMV now runs very smooth through USB.
So the new USB driver works!

Also Splinter Cell (through USB) "allows me" to go to 2nd training mission (previously it hangs at loading screen).

Maybe now USB compatibility could be the same as SMB?

Although I still have a problem with Street racing syndicate (crash after Namco logo) and with The fast and furious (crash after Nissan, Toyota screen).
These games will loads only if I, at cold boot will hold E1 launch key to boot OPL (the same situation is for SMB & USB).

Previously I have similar problem with Baldur's Gate II (at level "Firewind Manor I" game refuse to load cutscene, resulting a bug),
but it has been fixed.

Sometimes when I add\save compatibility mode in OPL, I'm getting stuck at orange debug color.

With one game I've strange problem, Ultimate Pro Pinball required mode 2 to run, with SCPH-50004 game runs normally,
but with 77004 I've only black at boot.
Without mode 2 I've at least splash screen, but the game will not boot.

Is there any differences between mode 2 for slim & fat models?

 

[sp193]

Fatal Frame should now be compatible.

The ghost has been captured on flim!

Good news everyone. I think I have come up with a valid fix for this game: initialize all registers to 0 before booting the game.
This is done by later Sony SDK revisions, but Fatal Frame was built with an earlier SDK that did not do this.

During my earlier testing runs, I only wiped the GPRs and found that it was sufficient. So the game might have been using an uninitialized GPR. Anyway, the new patch will initialize the registers, similar to how Sony eventually did.
It will clear most GPRs (except for $a0-$a3, $ra, $k0 and $k1), all FPU floating-point registers, facc and sa.

I have verified that the game probably doesn't access any memory below 0x00100000. I also tried wiping the memory there after the IOP reboot, but the game's behaviour did not improve.
So today I also dumped the memory of the PS2 right before SLUS_203.88 is booted, and compared the register contents. I also noticed that the content of the EE core did not actually matter - but the GUI's content (!). So that led me to check the registers and memory.

OPL was also found to be corrupting memory at 0x02000000 as well.

I've been testing OPL 1086 and I've notice that some FMV now runs very smooth through USB.
So the new USB driver works!

That is great news! Thanks.

Also Splinter Cell (through USB) "allows me" to go to 2nd training mission (previously it hangs at loading screen).

Maybe now USB compatibility could be the same as SMB?

Maybe. It is possible that it may be even better, since SMB mode is also constrained by memory issues.

Is there any differences between mode 2 for slim & fat models?

There are great differences between some PS2 generations. But in terms of functionality, they are equivalent.
The kernels are also supposed to be functionally equivalent, but there are differences around.
Sometimes, the differences lead to bugs being exposed.

Please check out the new commits (when they are merged). There may be games out there, other than Fatal Frame, which use registers before they are initialized.

 

[sp193]

I couldn't post on psx-scene, so I'll just put this here:

Regarding Disaster Report/SOS: The Final Escape:

Since I was doing somebody else a favour to fix another game, I did have another look at this series.

Since the sound playback is known to malfunction, it has got something to do with sound playback. So I checked how its sound driver was accessing files and it seemed to have quite good error-handling.

After walking for a while more, then suddenly:

dsidb S> cont
 at=000a0000  v0-1=ff0c0fcc,ff0c0fc0  a0-3=00000003,000b0780,006f16c8,000f10f0
 t0-7=00000003,00432880,00000001,000000b0, 00000000,00000000,00000000,00000000
 s0-7=000a5450,0000001d,0003000d,00000003, 0000000d,00000000,00000000,00000000
 t8=00000000 t9=00000000   k0=00033c4c k1=00000000   gp=000ad440 sp=006f16b8
 fp=006f17e0 ra=0009c558   lo=00000400 hi=00000000   PC=0009c628 bada=00001003
 $cr=0x1000001c [ CE1 Bus error (load/store) ]
 $sr=0x00000404 [ IM0 IEp ]
   <SE_Sequencer_Module+0x22f0>:
  0x0009c620: 0x00041080  sll     $v0,$a0,2
  0x0009c624: 0x00431021  addu    $v0,$v0,$v1
->0x0009c628: 0x8c420000  lw      $v0,0($v0)
  0x0009c62c: 0x2408ffff  li      $t0,-1
  0x0009c630: 0x1048ffcb  beq     $v0,$t0,0x0009c560  # <SE_Sequencer_Module+0x2230>
  0x0009c634| 0x00e23021  addu    $a2,$a3,$v0
  0x0009c638: 0x8cc20000  lw      $v0,0($a2)
dsidb S>

This happened within the Sony MODSESQ module. Since the IREMSND driver is not suspending interrupts and is calling the functions of various Sony sound modules from multiple threads (at least the tick thread and the RPC service), the IREMSND driver might be broken here. By documentation, the Sony sound functions are not thread-safe, and should not be called from multiple threads.

But because all imported sound functions are affected, I don't know how to easily test this (the patch will probably be huge).

There was actually a very simple locking mechanism, which involves a flag that can only be set by the RPC thread.
Unfortunately, replacing it with a semaphore did not help prevent the complicated sound module set from crashing...

I'll leave this here in case somebody has some better idea on how to fix this. It is the only new lead I got though.

I have stepped through all RPC commands issued to the IREMSND module.

Here is a list of issued commands (?? refers to other arguments that I cannot derive from the log itself, since I looked at the log after stepping through):

sndIopCmd_INIT
sndIopPcmCmd_SETDMACHPCM
SndIopSetMMIX(1, ??, 0)
sndIopCmd_SETEVOLMAX(0, 2)
sndIopCmd_SETEVOLMAX(1, 2)
sndIopCmd_SETMVOLMAX(0, 0)
sndIopCmd_SETMVOLMAX(1, 0)
sndIopCmd_SETBVOLMAX(1, 1)
sndIopHSynCmd_SETVOLMAX(0)
sndIopHSynCmd_SETVOLMAX(1)
sndIopHSynCmd_SETVOLMAX(2)
sndIopHSynCmd_SETVOLMAX(3)
sndIopHSynCmd_SETVOLMAX(4)
sndIopHSynCmd_SETVOLMAX(5)
sndIopCmd_SETBVOLMAX(0, 1)
sndIopCmd_SETEVOLMAX(0, 2)
sndIopCmd_SETEVOLMAX(1, 2)
SndIopHSyn_SETOUTMODE(?) & SndIopPcm_SETOUTMODE(?)
SndIopSetMMIX(0, ???, 1)
SndIopSetMMIX(0, ???, 0)
Get PCM playback status @ 00003c68
sndIopPcmCmd_STOPPCM
sndIopCmd_STOPALL
sndIopPcmCmd_STOPPCM
sndIopCmd_STOPALL
sndIopCmd_SETMVOL(0)
sndIopCmd_SETMVOL(1)
sndIopHSynCmd_READFILE
sndIopHSynCmd_TRANSBDPACKET
sndIopHSynCmd_SETHD
sndIopHSynCmd_READFILE
sndIopSesqCmd_SETSESQ(1, ??)
sndIopSesqCmd_SETPORTSESQ(0, ??)
sndIopHSynCmd_SETATTR(0, ??)
sndIopHSynCmd_READFILE
sndIopHSynCmd_TRANSBDPACKET
sndIopHSynCmd_SETHD(1, ??)
sndIopHSynCmd_READFILE
sndIopSesqCmd_SETSESQ(0, ??)
sndIopHSynCmd_SETPORTSESQ(1, ??)
sndIopHSynCmd_SETATTR(1, ??)
sndIopHSynCmd_READFILE
sndIopHSynCmd_TRANSBDPACKET
sndIopHSynCmd_SETHD(2, ??)
sndIopHSynCmd_READFILE
sndIopSesqCmd_SETSESQ(2, ??)
sndIopHSynCmd_SETPORTSESQ(2, ??)
sndIopHSynCmd_SETATTR(2, ??)
sndIopCmd_SETMVOL(0)
sndIopCmd_SETMVOL(1)
sndIopCmd_SETMVOL(0)
sndIopCmd_SETMVOL(1)
sndIopCmd_SETBVOL(1)
sndIopHSynCmd_SETVOL(0)
sndIopHSynCmd_SETVOL(1)
sndIopHSynCmd_SETVOL(2)
sndIopHSynCmd_SETVOL(3)
sndIopHSynCmd_SETVOL(4)
sndIopHSynCmd_SETVOL(5)
sndIopCmd_SETBVOL(0)
sndIopCmd_SETEVOL(0)
sndIopCmd_SETEVOL(1)

After this log, the noise starts.

Strangely, loading the IOP thread monitor (either before or after) would somehow fix the sound problem. I also managed to get it working once, while stepping through some stuff... but I don't know what it all means. Strangely, replicating only the code for thmon that would be run (when nothing is entered) into a new module, will not help.
Since I always break the EE for a while to look at the IOP, but that alone doesn't help with the sound problem.

I have always guessed that it was a race condition around some unprotected variables. But now I cannot find anything (under the assumption that nearly everything is done only by the tick and RPC threads). I have attempted to prevent any form of race conditions between the tick and RPC threads by patching in a new locking mechanism that utilizes a semaphore, but it has not improved.
I vaguely remember that the sound problem was also there under USB mode, but it has been a bit too long ago when I touched this.

PCM support seems to not be used at the boot screen and at the menu. It's first used when you start the game and the main character starts speaking.

I don't know what else to look at, so I'll leave this here.

 

[jolek]

That is great news! Thanks.

I should add, that I've better FMV performance with slim models.
With the same flash drive (I tried a few models), FMV on slim plays nice (sooth),
on FAT noticeable worse (it stil stutters, but less than it was before).

Please check out the new commits (when they are merged). There may be games out there, other than Fatal Frame, which use registers before they are initialized.

Thanks for that and a fix for Fatal Frame.

 

[sp193]

Potential game fix for SOS: The Final Escape. I think I might have got it.

The game suffered from a sound problem, which sometimes lead to instability.

There was a memo dated July 2000, which went along the lines of saying that the atick functions of modmidi and modhsyn should be called,
if related sequence data is stopepd and removed.

The explanation was that these modules only process sequence data when their atick functions are called.
If data is removed and their atick functions are not called before further callsto the library are made,
then the correct operation of the library cannot be guaranteed because the data would be dequeued.

So to correct this, the tick thread must be woken up after sequence data is dequeued.
While Sony documented that calling the atick function like this might result in a change in playback tempo, it is a small price to pay for such a simple patch.

Source: https://github.com/sp193/Open-PS2-Loader/tree/iremsnd-fix
Build: https://www.sendspace.com/file/6kgxxl

I haven't tested it, honestly. I did test it before I cleaned up the code (I was trying a lot of other things that I thought would help) and it worked, but a lot of things could have happened. No modes were required.
But because I have already spent quite a lot of time on the PS2 recently, I would like some others to also share the load with me. Thanks in advance!

On a side note, since the European version is newer than the original Japanese release, this might mean that they made the mistake elsewhere too.
Could somebody who owns the US and Japan releases send me a copy of their IOP/IREMSND.IRX and the main executable? (SLUS/SLPM/SLPS file)? Thanks in advance.