PS2 Open PS2 Loader v1.1.0

[TnA]

Sure... If someone works on them.

 

[Krah]

I would like to ask as many people as possible to test this OPL and report here if there are any problems. If you find a bug, then ALSO test if the bug is in the normal OPL 1572.

Tested UI: switching vmodes, themes, art, transitions, plasma, devices, audio, saving/loading cfgs.
Tested 3 Games: Shadow Man 2econd Coming (USA), Valkyrie Profile 2 (USA), Virtua Cop Elite Edition (EU).

For me almost everything was working as expected, only weird thing I could find is IGR combo on gcc10 build powers down my console where as standard r1572 does IGR (I tested the same game obviously).

 

[Maximus32]

Thank you for testing. It's good to hear most things work for you.

However, I've had problems with my SMB setup for quite some time, and today I got it fixed. Unfortunately in the gcc10 version SMB does not work .

I think the testing should be done to all different parts of OPL, like:
- GUI/CORE: USB mode (read + write)
- GUI/CORE: HDD mode (read + write)
- GUI/CORE: SMB mode (read + write)
- GUI/CORE: VMC (create + read + write)
- CORE: IGR
- GUI: Resolutions
- GUI: Sounds
- GUI: Themes
- etc, etc...

If we have a checklist we can use for testing new versions of OPL, we could be fairly sure most features are still working. We could also ask volunteers to check the checklist.

The thing that makes upgrading the toolchain so difficult is not even the toolchain itself, it's making sure all applications built with the old toolchain are still working. For me it would work best if I can just focus on the toolchain while others focus on testing/upgrading their existing projects.

 

[TnA]

@Grahf

It MIGHT actually influence game-compatibility, but it is unlikely.

A short technical explanation why:

1. The thing which affects game-compatibility the most, is the "disc driver(s)" which run on the secondary processor "IOP". The SDK&toolchain for the IOP was NOT updated, hence the compiled result should be exactly the same and hence compatibility should be exactly the same!
2. However... The EE (Main-CPU) side of the needed code DOES indeed change, thanks to the new SDK&Toolchain, hence there is a chance (although it is a small chance), that it could affect compatibility.

tl;dr
It is worth testing it, but the chances of singular game-compatibility increasing or decreasing is very small!

It should rather affect all or none (I suppose).

 

[Maximus32]

@Krah and others, could you please fill out this test form if you've tested OPL?

https://forms.gle/pyCE9AnrijEbUN817

Note that it's the first time I've used google forms, suggestions to do it differently or make changes are welcome. Are there any other tests that need to be done to make sure OPL works? I can easily add them.

 

[TnA]

Hm... The form doesn't mention, with which SDK the source/OPL was compiled with.

 

[Krah]

Hm... The form doesn't mention, with which SDK the source/OPL was compiled with.

Download location & hash should the able to determine that.

@Krah and others, could you please fill out this test form if you've tested OPL?

https://forms.gle/pyCE9AnrijEbUN817

Note that it's the first time I've used google forms, suggestions to do it differently or make changes are welcome. Are there any other tests that need to be done to make sure OPL works? I can easily add them.

I didn't think get to test as much as I would've liked but I don't have much time at the moment. Only other thing I would suggest is if we could leave notes eg IGR I put as no because technically it didn't work as I expected (reset) but it did power off so the "pad hook" still technically works.
Maybe a question for Lang files also?

 

[Maximus32]

Hm... The form doesn't mention, with which SDK the source/OPL was compiled with.

Download location & hash should the able to determine that.

Exactly.

I didn't think get to test as much as I would've liked but I don't have much time at the moment. Only other thing I would suggest is if we could leave notes eg IGR I put as no because technically it didn't work as I expected (reset) but it did power off so the "pad hook" still technically works.

I've added a last question where you can fill in a long text with additional information.

Maybe a question for Lang files also?

I've added a question about languages and fonts.

Can someone also test PADEMU and IGS?
And about IGS, does it still work on the latest OPL from ps2homebrew? Has anyone ever used this cool feature, or is it too difficult to use?

 

[Krah]

Can someone also test PADEMU and IGS?
And about IGS, does it still work on the latest OPL from ps2homebrew? Has anyone ever used this cool feature, or is it too difficult to use?

Tried to quickly test IGS, on gcc10 build I lose video signal whenever GSM is enabled so if that isn't on the form (I can't remember) it probably should be.

On normal r1572 GSM works fine. I tired IGS, first time using it so not sure exactly what happens; it flashes a few debug colours then gets stuck on a creamy kinda colour but nothing written to my MC..

AFAIK IGS has been broken on ps2homebrew for a while.. I believe @El_Patas has the revision number where it stopped working in a change log somewhere. I won't be able to test pademu. @jolek can you?

 

[Maximus32]

Tried to quickly test IGS, on gcc10 build I lose video signal whenever GSM is enabled so if that isn't on the form (I can't remember) it probably should be.

Added GSM to the form. You should also be able to edit the results after you've submitted them.
IGS depends on GSM, so if GSM does not work IGS will also not work.

On normal r1572 GSM works fine. I tired IGS, first time using it so not sure exactly what happens; it flashes a few debug colours then gets stuck on a creamy kinda colour but nothing written to my MC..

I think you need to insert a second MC into MC1. The file(s) should be saved in the format "mc1:/XXXX_yyy.zz_IGS(nnn).bmp". (link)

AFAIK IGS has been broken on ps2homebrew for a while.. I believe @El_Patas has the revision number where it stopped working in a change log somewhere. I won't be able to test pademu. @jolek can you?

We must be sure things work in the latest OPL. If IGS does not work, would you like to add an issue about it on github? We can then discuss if we should fix or remove the feature.

 

[jolek]

I won't be able to test pademu. @jolek can you?

Yes I can test PADEMU through BT or\and USB only with the DS3. I do not have the DS4.
I just need some time... Christmas, etc...
ETA 25\12\2020.

Added GSM to the form. You should also be able to edit the results after you've submitted them.
IGS depends on GSM, so if GSM does not work IGS will also not work.

AFAIK IGS has been broken on ps2homebrew for a while.. I believe @El_Patas has the revision number where it stopped working in a change log somewhere.

Additionally IGS also needs to have mode 6 off.
Anyway as @Krah mentioned, this feature has been disabled (or OPL was not compiled with it) for quite some time...
Or something got changed recently?

 

[deba5er]

I use SMB but should be able to setup a test for IGS with HDD or USB.
It is VERY game dependent though. So many games won't work with IGS.
As noted before you need to:
1) Enable GSM (I chose per-game NTSC). I don't think it is a good idea to get fancy with video modes so NTSC or PAL.
2) Insert a memory card in second slot and make sure it has a couple of MB free at least.

I know Smuggler's Run works (for IGS screen captures) on some recent OPL versions, although the button presses necessary bring up the map and capture it in the image.

Edit - Before I get deep into testing I want to note that SMB is working fine for me so far. My games and cover art show up and function as normal, and I can play Smuggler's Run at least. However, initial indications are that something is wrong with GSM (loses signal and hangs), which would of course prevent IGS from working.

Edit #2 - Noting that you list as 1572 but is actually version 1574 - a1d45b in attachment in post #1017

 

[Maximus32]

I've found the issue I had with SMB: When running a debug build, SMB does not work. But when running a release build, SMB works as expected. This is not an issue of the gcc10 version, so I'll make an issue about it on github and perhaps solve it.

Problems on the gcc10 build so far:
- IGR shuts down instead of reset
- GSM results in black screen

I've been investigating the GSM code in ee_core. It's 90% assembly with lots of macro's to choose between the old/new toolchain. It is likely related to the ABI change from EABI to N32: registers are named differently and parameters are passed to functions differently.
- check all entry points from interrupt/BIOS/GAME, they should still be EABI compatible?
- check all entry points from OPL "C" code, they should be EABI for old, and N32 for new toolchain

@uyjulian do you have any idea what could be wrong here?
https://github.com/ps2homebrew/Open-PS2-Loader/commit/8487ed7416482c79a4d06e149982966713b5e21a

 

[jolek]

I have checked PADEMU with Fight Night Round 3 and with RE4, currently only through BT (wireless) with DS3.
In FNR3 I have tested vibration and overall gameplay. Everything was fine.

In RE4 I have only tested vibration in settings, because long time ago there was a problem with that.
I know that the problem has been fixed, but I only wanted to check\know if maybe there was some kind of a regression...
Everything was also fine.

As for GSM... in I think WIP OPL 1574.
When I enable 576p I have only a tiny picture on my TV:

A few things that I still do not like... or are problematic:
- The PS2 has only two USB ports. I know that I can get a USB hub, but for me it will be a workaround...
When I want to test PADEMU through BT...
A USB BT dongle has to be in one USB port,
If I want to test a USB device, second port will be also reserved.
All the settings for pairing DS3 with a USB BT dongle are under games list...

So to pair the DS3 with a USB BT dongle I have to pull out a USB device,
connect the DS3 through a USB port and pair.
If I accidentally press to go back, OPL will freeze.
I have to repeat the whole process once again which is a bit frustrating.

Can at least an options to pair a USB BT dongle with the DS3\DS4 be... somewhere else\in a different place?

- OPL is taking a lot of time to boot when I'm using a USB device:
https://github.com/ps2homebrew/Open-PS2-Loader/issues/300.
In e.g. OPL 1442 the whole process is taking few seconds to boot and shows games list with a USB device.

-When a PS1 MC will be inserted, OPL will update game history.
Unfortunately it causes to create corrupted data on that MC:
https://github.com/ps2homebrew/Open-PS2-Loader/issues/284.

 

[uyjulian]

@uyjulian do you have any idea what could be wrong here?
https://github.com/ps2homebrew/Open-PS2-Loader/commit/8487ed7416482c79a4d06e149982966713b5e21a

I'm not too sure. I just replaced tX with aX so that it assembles with the new assembler. This is similar to the changes I saw before in ps2sdk.

 

[sp193]

Problems on the gcc10 build so far:
- IGR shuts down instead of reset

The code for IGR is in padhook.c. It installs a V-Blank End handler, IGR_Intc_Handler(), which polls the pad region every tick for the button combo. The action to take, is determined based on this.

Assuming the code was working fine, I think it could be a case of memory corruption (causing the selection to get changed), or GCC aggressively optimizing things in ways that are unacceptable.

- GSM results in black screen

I've been investigating the GSM code in ee_core. It's 90% assembly with lots of macro's to choose between the old/new toolchain. It is likely related to the ABI change from EABI to N32: registers are named differently and parameters are passed to functions differently.
- check all entry points from interrupt/BIOS/GAME, they should still be EABI compatible?
- check all entry points from OPL "C" code, they should be EABI for old, and N32 for new toolchain

GSM doesn't really integrate with the rest of OPL. By "integration", it is just:

• Integration into the UI.
• Integration into our EE core application, for better control over the limited user memory we have. However, the code generally only interacts with the EE kernel.

The MIPS Level 2 Debug exception handler is replaced to hook onto specific writes to the GS priviledged registers (which are write-only) with Install_GSHandler() and SetGsCrt() is hooked with Hook_SetGsCrt(). SetGsCrt() is hooked so that we can influence the parameters passed to it and also learn about the game's selected video mode.

Since most of GSM revolves around the Level 2 Debug exception handler, the assembler code in gsm_engine.S generally does not represent complete functions. Except for perhaps the SetGsCrt hook.

Perhaps you might want to compare the generated instructions against the original in gsm_engine.S and gsm_engine_adv.S?

 

[Maximus32]

Perhaps you might want to compare the generated instructions against the original in gsm_engine.S and gsm_engine_adv.S?

Thank, this helped. Turned out the generated assembly was not the same. Mostly becouse some registers ($t0...$t3) exists in BOTH the old and the new toolchain, but point to a different register. I've extended the "as_reg_compat.h" file to be more specific about what ABI is used.:
https://github.com/ps2dev/ps2sdk/blob/ee-toolchain-gcc10/common/include/as_reg_compat.h

With this and a few other changed GSM is now working as expected. The only problem left should be IGR.

New gcc10 test build (4de25a0) available here:
https://github.com/rickgaiser/Open-PS2-Loader/releases/tag/latest

Please let me know here or in the test form if there's anything wrong (other that IGR and existing problems).

 

[jolek]

I only made a quick test with loading OPL with a USB device.

OPL 1442 needs ~12 sec to boots fully.
OPL_1575-Beta-583dfe0 needs ~14 sec to boots fully. https://github.com/rickgaiser/Open-PS2-Loader/actions/runs/443118800
OPL_1579-Beta-4de25a0 needs ~22 sec to boots fully.

All "tests" were made with "games.bin" in "CD" and "DVD" folders.

 

[Maximus32]

The workaround I created for booting faster from USB (and possibly other devices) is currently in a PR here:
https://github.com/ps2homebrew/Open-PS2-Loader/pull/342

It's not part of the gcc10 test build. Once these changes are pulled I will also include them in the gcc10 test build.

 

[jolek]

OPL_1581-Beta-a2b2efc needs ~14 sec to boots fully, so the same amount of time as OPL_1575-Beta-583dfe0 as you said.
I also checked a problem with loading translation from mc and special characters.

Everything seems to be fine:

LNG loaded from mc1:

LNG loaded from mass0:

EDIT: IGR and GSM (tested only 576p) seems to work, at least through a USB device.

Spoiler: Other issues that are known

• When a PS1 MC will be inserted, an OPL will update game history.
  Unfortunately it cause to create corrupted data on that MC:
  https://github.com/ps2homebrew/Open-PS2-Loader/issues/284.
  
  
• An OPL will freeze e.g. on HDD Games page when a power off button will be tap
  instead of turning off the console.
  
  
• When an OPL is doing something in background ()
  and I will try to reboot it or shut it down it will freeze:
  https://github.com/ps2homebrew/Open-PS2-Loader/issues/312.
  
  
• Few (at least 5) in-game reboots will crash\freeze game:
  https://github.com/ps2homebrew/Open-PS2-Loader/issues/231.