Separating the GUI from the ee-/iop-core

[rickgaiser]

I would like to discuss what would be the best approach to doing this, since it can be done in many ways. But first, what parts does loading a game consists of:

1. CORE-LOADER (OPL / mini-OPL / OPL-core)
--------------
Loads all IOP modules and the EE-CORE into place, and starts EE-CORE.

2. EE-CORE
----------
Starts all IOP modules

3. IOP Base system
------------------
ioprp.irx
imgdrv.irx
udnl.irx
reset_spu.irx

4. IOP CDVD emulation
---------------------
cdvdfsv.irx
hdd_cdvdman.irx
smb_cdvdman.irx
- smstcpip.irx
- smap.irx
- smbinit.irx
bdm_cdvdman.irx
- USB:
  - usbd.irx       (ps2sdk)
  - usbmass_bd.irx (ps2sdk)
- i.LINK:
  - ilink.irx      (ps2sdk)
  - ilink_bd.irx   (ps2sdk)
- MX4SIO:
  - mx4sio_bd.irx  (ps2sdk)

5. IOP Extra emulation
----------------------
mcemu.irx
pademu.irx

6. IOP Debugging
----------------
drvtif_ingame.irx (deci2)
tifinet_ingame.irx (deci2)
udptty_ingame.irx
ioptrap.irx

Idea 1: 'mini-OPL'

Separate both the eecore and the iopcore into a separate "OPL-core" (just like "mini-OPL"). And leave the rest as "OPL-gui". The OPL-core would be started using command line arguments. The same core can be used for launching games from OPL-gui, RetroArch, wLaunchELF and another (coverflow?) launcher. Also this core would be very suitable for launching games from HDDOSD. Also for testing over ps2client/ps2link, the OPL-core would be very easy to test.

There's a few downsides however:

• The user needs to update OPL in 2 places
• The total size of both modules is a little larger, since shared irx files would have to be in both executables.
• All above mentioned parts are still in 1 big executable 'opl-core.elf' / 'mini-opl.elf'

The OPL folder structure could look something like:

opl\cores\v1_0\oplcore.elf
opl\cores\v1_1\oplcore.elf

Idea 2: 'modular core'

Instead of embedding the EECORE and all needed IRX files into OPL, we could also load them from a folder inside the OPL folder. Allowing the user full control over what specific versions of what modules to load. For instance an old version of smstcpip.irx that was faster, or a custom version of usbd.irx that is more compatible. The folder structure could look something like:

opl\cores\v1_0\eecore.elf
opl\cores\v1_0\cdvdfsv.irx
opl\cores\v1_0\hdd_cdvdman.irx
opl\cores\v1_0\smb_cdvdman.irx
opl\cores\v1_0\smstcpip.irx
opl\cores\v1_0\smap.irx
opl\cores\v1_0\smbinit.irx
opl\cores\v1_0\mcemu.irx
opl\cores\v1_0\pademu.irx

Both idea 1 and 2 could also be combined. Making a very small oplcore.elf, that loads modules from a specified location.

@KrahJohlito has already started working on something that looks like Idea2. So let me know what you think of the idea. Any other/better/more simple ideas? Don't split them? All ideas / comments welcome.

EDIT: Debug modules added

[AKuHAK]

This still sounds like a lot of work for any choice, so I think that this should only depend on the actual developer's decision. The only thing: I think that in any case there should be something like a "failsafe" configuration. So, we can just tell the user: "just remove all modules from the folder and check again". I mean that modular modules should be more optional or extendable, not the necessary part, or at least the main opl.elf should contain a default set of all necessary modules.

[rickgaiser]

For the 'modular core' idea it makes sense to have the latest modules embedded, just like it is now. Only adding the option to override some or all modules (including eecore.elf!). This has been possible for usbd.irx some time ago (before bdm merge).

For the 'mini-OPL' idea I don't think it makes sense to embed a complete core. The gui and the core would be truely separated. I think we should even separate this git project into 2 different projects. Both with it's own releases and version numbers.

[KrahJohlito]

Yea I’m not sure tbh, I have a poc here KrahJohlito@90b998d for idea2 if you guys wanna take a quick look, readded modes 7 & 8 to GUI if core version is 093.
I’m happy to keep working on it, leave it for someone else or to just forget about the idea.

But so many questions.. using this method we could remove compile option for pademu in GUI and just have it core dependant but what happens with debug modules? Do we default to compiled in modules and that is where development continues for the core or separate repo? Or do we just go with idea1.. I have questions relating to that also lol.. or maybe it’s best to just stick with status quo and don’t split?

It would be good if we could come to a general conscientious @ps2homebrew
@uyjulian @fjtrujy @bignaux @BatRastard @parrado @sp193

[rickgaiser]

Seems like you have 'modular core' almost finished and ready for merge ;).

How the gui loads and passes parameters to the core has changed over time. If we want to split the core from the gui then we must make sure this interface stays compatible. Like mode 7/8, but also what modules are needed, what parameters to pass to GSM, etc. Seems like you changed old cores to be compatible with new gui's. For future changes I think we should keep the GUI compatible with existing cores.

The core selection list is a fixed list. Can you make that into a list that shows the folder names? Just like selecting a theme. This would make it more easy to add and select all sorts of folders.

PADEMU compile option is a good question, and leads me to another question: If a module does not exist in a core folder, does that mean it should not be loaded, or that the default module will be loaded? Should core folders be considered 'complete', and no other modules loaded. Or should core folders be considered 'overrides', and use the default for all other modules? I think it would be usefull to support both 'complete' and 'override' folders. Supporting the 'complete' folder type also makes not loading usbmass_bd.irx for v9_3 cores more flexible. Or pademu/mcemu/etc..

[KrahJohlito]

The core selection list is a fixed list. Can you make that into a list that shows the folder names? Just like selecting a theme. This would make it more easy to add and select all sorts of folders.

I can but that might make it difficult to determine the version to know if to show modes 7/8 if the versions aren’t enumerated?

Also I think complete cores might be the way to go, just because I’m not sure if we can mix and match all different modules? I quickly tried editing 093 core elf to accept pademu args and using 093 modules for cdvd emulation & 110 modules for mcemu & usbd as a quick dirty hack to get pademu on 093 but it didn’t work.. it’s possible I made an error somewhere though.

[BatRastard]

This and what uyjulian says below works for me!

[uyjulian]

If idea 2 is used, I think it would be a good idea to use some sort of archive file like zip to group the elf/irx together (in addition to loose files on the filesystem).

I'll throw in another idea in the mix:
GUI will prepare the IOP and put loader/eecore elf, irx, (or just a combined elf), config files etc there. (IOP ramdisk?).
GUI will load loader elf from IOP, with the path to the aforementioned files as command line argument (No IOP reset is done here, as it would destroy the prepared ioman environment).
Loader elf would read eecore elf, irx, config files etc. Once that is done the IOP is rebooted, and the environment for ee core prepared.

This would allow a separate "backwards compatible" loader elf while newer loader elf could change the EE core interface in backwards incompatible ways. The interface that just needs to stay stable is the config file interface, and that could use an extensible format like BSON, JSON, or XML.

This infrastructure could also be partially reused for homebrew that rely on the environment prepared by uLaunchELF.

[KrahJohlito]

Quickly added zip support KrahJohlito@bff07d8 , had a quick look in sdk & ports couldn’t see a library to use so just used this zip code from http://www.winimage.com/zLibDll/minizip.html .. if there is a better way can you suggest what lib to use? Thanks

This is happening at game launch also so it might slow that down a bit especially with USB? But idk only did a quick test to see if it worked.

Edit: updated zip source files.. old ones we're from the only ps2homebrew I could see that uses zip format (pgen/fceumm/opl 0.7)