Future features?

[nodots]

I was wondering if it's possible for future inclusion of some features from the HOSDSYS update? I would really like to use the main menu for browsing/booting games/ELF's. I have seen videos of KERMIT's ODEM making game partitions boot from the HOSDSYS... Would be nice to see from my TV instead of youtube.

Also would be nice to put the ELF's to be run from OSDSYS on a single partition, instead of my memcard, (or each on their own partition like in the videos). This feature first? If I knew as much C as I do bash script, I'd offer to help - but I'm learning (OPL source).

I noticed that there is no "stickied" feature request page, and the devs on this are few, so I'm probably talking out my arse here.

Great job so far, though! Never thought I'd see the day of a softmod...

[SP193]

I was wondering if it's possible for future inclusion of some features from the HOSDSYS update? I would really like to use the main menu for browsing/booting games/ELF's. I have seen videos of KERMIT's ODEM making game partitions boot from the HOSDSYS... Would be nice to see from my TV instead of youtube.

We're working on making HDLoader-format games bootable from the HDD OSD.

Just don't expect it to be released anytime soon, as the installer and so on have yet to be completed.

HDL installers won't do the job because they don't install the required files into the partition Extended Attribute Area.

Also would be nice to put the ELF's to be run from OSDSYS on a single partition, instead of my memcard, (or each on their own partition like in the videos). This feature first? If I knew as much C as I do bash script, I'd offer to help - but I'm learning (OPL source).

That might not be possible with the SCE OSDSYS, unless it gets hacked to not require signed ELF files. All ELF files must be signed in order to be bootable from the HDD unit.

[nodots]

HDL installers won't do the job because they don't install the required files into the partition Extended Attribute Area.

Actually, I figured that this would be a separate program to do this (One that would rip the game also), or even better... Even a call to OPL/HDL with parameters on what to load might work (that seems simple enough). Then OPL/HDL could store the settings it's self, from it's own GUI. You just bypass the GUI once the game was set up properly. No need for RIOTW, I like OPL

That might not be possible with the SCE OSDSYS, unless it gets hacked to not require signed ELF files. All ELF files must be signed in order to be bootable from the HDD unit.

I'm not meaning "bootable", just runable. This is not in reference to using HOSDSYS, but in lieu of it (partial emulation, better functionality)?

Actually, I have no idea how FMCB does it's job... Does it replace, append or patch the OSDSYS in ROM? That is kinda important for understanding what can be done with FMCB, and making suggestions intelligently.

What are the odds of making use of an IRX for HDD/PFS support, for an APPS partition? For the APPS partition, you would still have to manage it using uLE. You are just able to run an app from the first screen menu, like running BOOT ELF (uLE) from the MC in a fresh "noob install". That's what I meant by APPS partition... From FMCB menu, not instead of.

Just some thoughts. I don't need these features, they would just be great to have... A great job has been done already!

[SP193]

I'm not meaning "bootable", just runable. This is not in reference to using HOSDSYS, but in lieu of it (partial emulation, better functionality)?

If I've understood you correctly now, you meant to ask whether it is possible to make programs runnable from the hacked OSDSYS menu offered by FMCB.

In that case, I can't give you an answer to that because I have no control over FMCB's development.

Actually, I have no idea how FMCB does it's job... Does it replace, append or patch the OSDSYS in ROM? That is kinda important for understanding what can be done with FMCB, and making suggestions intelligently.

It patches a copy of rom0:OSDSYS before executing it.

FMCB relies on the OSDSYS update functionality found in all PS2 BIOS versions up to v2.30. As it's name suggests, it's a mechanism designed for booting an update program, which is usually includes a replacement OSDSYS program.

So far, the only console series to have such an update deployed are the SCPH-10000 and SCPH-15000 series of consoles. They lack the necessary modules in their ROM chips for supporting their external HDD units, hence an update was necessary for booting from the HDD unit.

What are the odds of making use of an IRX for HDD/PFS support, for an APPS partition? For the APPS partition, you would still have to manage it using uLE. You are just able to run an app from the first screen menu, like running BOOT ELF (uLE) from the MC in a fresh "noob install". That's what I meant by APPS partition... From FMCB menu, not instead of.

While it was always possible for executables to be launched from the HDD (uLaunchELF can already do that), the only problem is that FMCB does not support the HDD at all.

There is a reason for that - the developers did not want to make FMCB more bloated than it already is, especially since uLaunchELF could be used to launch programs from all sorts of devices. That was their decision, and it has been discussed before on this forum board.

If I was allowed to make a suggestion, I would have suggested that the developers opt for a modular approach for device support - like I did for the PS2ESDL v0.820 series.
That way - the users will be allowed to choose the devices that will be supported.

Right now, there is no way to add HDD support to FMCB because it was never designed for that.

[nodots]

If I've understood you correctly now, you meant to ask whether it is possible to make programs runnable from the hacked OSDSYS menu offered by FMCB.

Yes, you understand. In an ideal design, uLE would mostly be a file manager, as the necessity to run it just to run apps off the HDD would be obsolete. uLE could still be used, however it would not be required.

It patches a copy of rom0:OSDSYS before executing it.

That explains alot.

There is a reason for that - the developers did not want to make FMCB more bloated than it already is, especially since uLaunchELF could be used to launch programs from all sorts of devices. That was their decision, and it has been discussed before on this forum board.

Well, now that it is half the size it was for 1_7, maybe it might get included?

If I was allowed to make a suggestion, I would have suggested that the developers opt for a modular approach for device support - like I did for the PS2ESDL v0.820 series.
That way - the users will be allowed to choose the devices that will be supported.

I totally agree. I like the idea of the user being in more control. I am a Linux and BSD user.

Right now, there is no way to add HDD support to FMCB because it was never designed for that.

Maybe in 2_0? That could be the "major change"?

I am looking through OPL/uLE source, so I can find out how an IRX is loaded and made use of. I might have a look into HOSDSYS to make further suggestions. I am learning C, but I know ASM well enough.

Am I correct to believe that arguments can be passed to a loaded program? If so - in added menu items, is it possible (like in DOS, just tack it onto the end)?

[SP193]

Well, now that it is half the size it was for 1_7, maybe it might get included?

Maybe. But like I've said earlier, nothing can be done about it because FMCB is closed-source and the authors have made their decision.

Maybe in 2_0? That could be the "major change"?

Maybe.

I am looking through OPL/uLE source, so I can find out how an IRX is loaded and made use of. I might have a look into HOSDSYS to make further suggestions. I am learning C, but I know ASM well enough.

Take your time though. The PS2 is considerably different from the regular PC, and so programming it is a little different.

Am I correct to believe that arguments can be passed to a loaded program? If so - in added menu items, is it possible (like in DOS, just tack it onto the end)?

Yes, arguments can be passed to the next program. It works basically in the same way.

One difference is that there is no command line, so arguments get passed via the ExecPS2(), LoadExecPS2() or some other method in argc and argv directly.

[nodots]

Yes, arguments can be passed to the next program. It works basically in the same way.

You failed to mention if FMCB does this. It's alright though, not like I can make use of the knowledge yet. I am wading through source still.

As the PS2 is my first platform to learn C on, I imagine that this won't be to difficult to tackle. I find motivation easy, as the hardware is so fascinating!

[SP193]

You failed to mention if FMCB does this. It's alright though, not like I can make use of the knowledge yet. I am wading through source still.

As the PS2 is my first platform to learn C on, I imagine that this won't be to difficult to tackle. I find motivation easy, as the hardware is so fascinating!

I didn't think that it was necessary, since it's normal for the first argument to be the path to the executable itself.

If you need FMCB to pass additional arguments, FMCB needs to be modified.

[nodots]

Thanks a bunch! I think you have given me all the knowledge that I need to plan a project... After browsing the source I have available, I think I can so something with this...

Everybody stand back! A new programmer is here to mess up code! LOL.

[mrcordas]

Hello programmers here in the forum!
I am also learning C / C + +, use a bit familiar with linux. you could indicate or send me documents about programming Ps2 (commands, libraries, routines)?
always compiled the Ule and OPL, but was taking a look at the source code, and is bone!