PS2 mini-OPL v1.0

J

jsnepo

Member
Anyway to compile OPL v1.0 to run games directly from the HDDOSD (with the Playstation 2 splash screen) like how miniOPL does it?
 
It is to large. APA have space for executable some around 800KiB.

What can be done is loader which would just been used as bootable app for HDL/OPL partitions and which launching e.g "hdd0:/+OPL/OPL.ELF". But You must find some programmer which would write it.
 
Stripping the GUI and unrelated cores would make it much smaller. ;)
Hence "Mini-OPL"! I like the idea, but it would require some work.

It would be interesting to have a build time function for this, IMO.
Then we could build a Mini-OPL out of every new build.
 
TnA said:
Stripping the GUI and unrelated cores would make it much smaller. ;)
Hence "Mini-OPL"! I like the idea, but it would require some work.

It would be interesting to have a build time function for this, IMO.
Then we could build a Mini-OPL out of every new build.
Click to expand...

Yeah. I was hoping we get an updated one. I was using diskload from HDLGameinstaller and before that, this one build that came from somewhere called mini-OPL. Hopefully we get one with the OPL v1.0 build.
 
That's rather a "feature", possibly for OPL 1.2.0! ;)

OPL 1.1.0 seems to be quite close, because BDM got merged into the official OPL Beta-builds and we are on GCC11 now!
 
That's actually a good idea, BUT also requires that a partition is mendatory where OPL could be stored.

So... If OPL could support starting a game via arguments, a Loader for OPL could "simply" retrieve the partition/path it was loaded/started from and could execute OPL with the path passed as arg.

Pro:
  • OPL could be updated very simply (only 1 file) and it wouldn't need to update every partition-info. Additionally this replacement is done on a filesystem-level, which might be "safer".
  • OPL could use the normal settings (modes, GSM, PADEMU, VMCs, etc.) for the game, if it knows which one it is.
  • Loader-Payload could be quite small and simple and hence be used in multiple "limited Payload size"-scenarios.
  • etc.
Con:
  • Mendatory partition, but some partitions are USUALLY set up anyway. Simplest solution is +OPL or a system-partition.
  • etc.?
 
Loader could load a config file from +OPL or a system partition, and the config file could then specify where to load OPL. Perhaps there's room in the header for a simple config too? And the HDL header already has modes (although they're not the same as current day OPL modes) and could possibly pass those to OPL.
 
My concept is a little different. More simple. Let's factorize it:
  1. loader is uncompressed and OPL destination is written on bit field, easy to edit via hex editor (let's say that default path is "hdd0:/PP.FHDB.APPS/OPL.ELF" (peoples which installing FHDB with /APPS filled with ELFs get this partition created; personally I'm using my own idea "hdd0:/PP.HOMEBREW/apps/<app dir>/<app>.elf" but it doesn't matter now))
  2. user write it's own path or use the default one whatever it is, and write executable into APA space like in every PP. or PC. partition
  3. user choosing game, so HDD OSD launching loader from APA
  4. loader looking for OPL path written in his field and run OPL
And here are our concepts differences. I would just run standard OPL, without any args etc. So everything later is handled by standard OPL, with standard GUI. So user must choose game manually, etc.

This solution is not transparent as OPL Mini which already launch OPL which automatically run the game. Also this is not transparent as launching OPL by loader "in a special way" which automatically run the game. So consider it as just alternative OPL loading, not game itself (from user point of view). Someone can say that this doesn't have sense. But it is only way to provide solution, not depended of OPL development (You know, one day maybe some arguments will change, or some game stopped working).

There is not best solution here as Sony designed this stupid APA... And what future could brings? We have already working BDM, so in future, we could just put disc images in PFS, exFAT or whatever space, instead of use fs space as raw bit stream. And all this OPL Mini stuff which taking resources (I mean: human time for QA) will be wasted.

- - -
BTW: I'm against +OPL, the best place for it is "hdd0:/__common/OPL/" (I saw issue opened with this proposition and I'm stand with @akuhak with this idea) or $appdir. I hope it will be added as option (i.e OPL would checking paths before without user agree create his partition, to small anyway to put all covers, vmc etc...). How it is related to the thread? You mentioned the config handled by OPL - in this way, we don't need any special partition at all.

- - -
@Darkshadow_ APA is split into sections. First bytes is the header as You know with checksum, partition name, parts etc. Later is empty, not used by anyone, could fit even game config, and later are address for stuff (icon file, meta file for icon, system.cnf, signed executable and one thing about I forgot; but those cannot be used, moved etc).
 
Most people wouldn't want to edit the ELF with a hex editor. It's not very user friendly and really easy to edit it wrong and get a non functioning ELF. Especially because you need to make sure the length of the string field stays the same, so if the path you're replacing is longer, you need to remove some, or if it is shorter, you need to add some to insure this. It's easy to forget that (or just not know it needs to be done that way).

The loader should have some kind of built in path, but a config file to override where it loads OPL from would be nice and much easier to do and maintain. If you ever decide to move OPL to somewhere else, it's easier to change the config than need to load up a hex editor, change the field, and then go and insert that changed loader into all of your game partitions.

The idea of putting the config file in the header was just an idea I was throwing out there. A single config on a partition would be easier, though, because if you wanted to change it and it was part of the header, then you're back to having to insert that changed config back into all of your game partitions.
 
That's true, however most peoples also do not write executable into APA because there is no user friendly tools for that. So actually we are walking on the same circle.

Such field can be very long. SP193 wrote for me loader for AIO, and unused symbols can be 00h, so I do not to aware of shortening paths or moving sections in ELF. I have in mind something like this:
opl_ldr_poc.png


For end and ordinary user, of course the easiest way is... OPL Mini, or loader + some changes on OPL side to take the args as TnA said. But this have some flaws which I mentioned above. Whatever the road we took, all three solutions will be limited in some ways.
 
Last edited:
Yes, the length helps in case you want to make the path longer. If it was the exact length, then you couldn't change it to a longer path. But by adding or removing, I did mean 00h (which is NUL, or the end of string terminator in programs).

In the above case, it looks like the string's storage is 191 characters total (which is an odd value, usually it's 255 for paths), of which 78 are being used for the path and the rest are NULs (00h). If you wanted to change it to "hdd0:pfs:/PP.HOMEBREW/apps/OPL/opl.elf", then afterwards you'd need to add in 32 NULs (00h) after the end to make up the difference, or the ELF file will likely not work right (likely crash) as offsets in the executable won't point to what they were supposed to point to.

Same for making a longer path. If you changed it to "hdd0:pfs:/PP.HOMEBREW/apps/Open PS2 Loader/OPNPS2LD-v1.1.0-Beta-1635-1101a9d.ELF" you would need to remove 3 of the 00h after it to keep it the same length.

It's actually pretty easy to add / update an executable in the header with hdl_dump with the modify_header command. Also, HDLGameInstaller puts in miniOPL as the executable, and has an option to update all game partition's version of it. If someone updated it with the loader, then all anyone would need to do was run HDLGameInstaller and use that option to get the loader installed.
 
It doesn't exist, it is just an example handmade how this would looks like, as image is better than words. ^^ AIO Loader only supports discs, otherwise I would publish it already with the description how to use.

Yes, and this is the reason why ends by so many 00h - to replace them if needed (longer path) or replacing unused symbols by them (for shorter path) to keeps always the same executable size.
 
@jsnepo You can use as substitute this project: https://www.psx-place.com/threads/softdev2-mbr-kelf-poc-wip.33537/page-3

What I exactly have in mind:
  1. take XMB.XLF and decrypt it by any kelftool
  2. open ELF in hex editor and change partition name from "PP.SOFTDEV2.APPS" to place where You have OPL (it must be shorter or equal to fit into byte field, if shorter, replace empty places by zeroes); the same do with dir name and OPL on this partition (the same rules as above)
  3. encrypt elf file by this tool: https://www.psx-place.com/resources/kelftool-fmcb-compatible-fork.1104/
  4. Using HDL Dump, inject modified and encrypted elf to APA header (so You need to prepare also system.cnf for PP/PC partition; details You can find in APA Partitionology tutorial) of game partition.
And that's it. Launching PP partition will cause to launch OPL placed in place where You have it. This will always works with any OPL, no matter what version is, as long as names match, and of course it doesn't load game but OPL application so of course it is not the same as OPL Mini.
 
Berion said:
And that's it. Launching PP partition will cause to launch OPL placed in place where You have it. This will always works with any OPL, no matter what version is, as long as names match, and of course it doesn't load game but OPL application so of course it is not the same as OPL Mini.
Click to expand...

So it will launch the OPL GUI? I've done something like that. I got OPL v1.0 to launch from the HDDOSD. I was hoping to launch the game from the HDDOSD using v1.0 of OPL and not whatever build the latest miniOPL or diskload is.
 
For direct launching games we need OPL Mini. And for making it flexible, to read also game configs.

So yes, what I said above is for launching OPL just like for launching it in any other way.
 
Well I had a quick go at launch args..so the idea is.. OPL-Launcher.ELF (attached) is injected into header, which boots and sends args to hdd0:PP.OPL/OPL/OPNPS2LD.ELF (attached) which parses the args and boots the game (while using game cfg if it exists on OPL partition)..

However, I feel that I'm going to lose interest before I actually get another HDD to test it..so here it is..untested, use at your own risk etc.. it'll either work or just kick back to HDDOSD.. if someone can test and it does work, I'll spend more time on it :-P
 

Attachments

  • Like
Reactions: TnA
Krah said:
Well I had a quick go at launch args..so the idea is.. OPL-Launcher.ELF (attached) is injected into header, which boots and sends args to hdd0:PP.OPL/OPL/OPNPS2LD.ELF (attached) which parses the args and boots the game (while using game cfg if it exists on OPL partition)..

However, I feel that I'm going to lose interest before I actually get another HDD to test it..so here it is..untested, use at your own risk etc.. it'll either work or just kick back to HDDOSD.. if someone can test and it does work, I'll spend more time on it :-p
Click to expand...

I tried your launcher. It booted me back to HDDOSD. Just wanted to be sure there's an OPL folder inside the PP.OPL partition.
 
You must log in or register to reply here.

Similar threads

Back
Top