PS2 FMCB/FHDB v1.9 series release thread
- Thread starter sp193
- Start date
-
- Tags
- fhdb fmcb fmcbinstaller
sp193
Developer
FMCB v1.964 Released!
This is mainly for users of the SCPH-10000, SCPH-15000 and SCPH-18000.
Changelog for FMCB+FHDB v1.964:
NEW: New changes that were made since the initial releases.
The HDDLOAD.IRX file is part of FMCB, which is used to locate the update on the HDD unit (I guess, you would use FHDB as the HDD update).
Downloads/Links
FMCB + FHDB + installer project page (downloads at bottom): https://sites.google.com/view/ysai187/home/projects/fmcbfhdb
For at least now, I won't add an option for sorting because I don't want to touch LaunchELF's code (which is used for the configurator).
EDIT: Replaced file.
EDIT: updated LaunchELF + USBHDFSD. The fix to USBHDFSD probably won't matter here, but just in case.
It's a limitation because it has to fit where the OSD will not use.
But as you wrote before, the current amount of space given to it is actually quite a lot. I have increased the maximum number of items to 256.
I'm not very sure what you mean here, sorry. These are all different projects.
What I meant was that the three versions of FMCB, are from the same tree. But that's only for FMCB.
If you mean to say that I could have done the same thing for my other projects, you are not wrong.
I did merge the standalone fsck tool back into HDDChecker's source code, although HDLGameUpdater might have to remain separate because HDLGameInstaller is just too big to make it work right.
I have my doubts. But I just haven't done anything yet because there will be too much work. Although I think it can be nice, since people do browse Github.
Some of these projects (HDLGameInstaller and PS2ESDL) have a few hundred versions. They've been in development for years, even before I wrote about them anywhere.
Honestly, no. I just found it challenging to make it work across all possible software revisions. The patterns can change, even if the compiler was changed.
Oh it's more than that. Recently, we found that the hardware itself might have various problems.
It just can't be made to have performance on its own, without issues.
Thanks for the encouragements and the insights.
After the occasional defacement cases of FMCB, Jimmi did add something for obfuscating the logo for FMCB v1.8c.
I went a step further, to make it more difficult to disassemble. Since it's closed source, that would be the only way to ensure that nobody would deface the logo to sell it as their own product.
But now that we're in 2018, I replaced it with the normal packer that I use for my other projects.
Ah, I see. Thanks
I'm sorry that I couldn't meet your expectations. Essentially, what the new versions of FMCB do, is whatever the previous ones do, but are more complete and reliable.
For example, it boots up faster because there is cleaner and shorter initialization code, copied from the Sony browsers. The old versions had a lot more stuff, I guess because ffgriever got his information from some other indirect way (i.e. logging from pcsx2 etc). The initialization code is also more correct and applicable to all PlayStation 2 consoles, instead of just the mainstream consoles.
Due to the contribution of an anonymous user, we were also able to be free of using a DVD Player KELF, so FMCB installations actually became smaller (62KB instead of 75KB).
There's also support for DVD Player updates, for all consoles (not just Japan, Europe and USA). While the original intent was for the SCPH-10000 and SCPH-15000 (which have no DVD player built in), the mechanism can be used to boot region-free DVD players as well.
Then we also had the USB modules updated. Initially it was just for reliability, but now they seem better at performance too. There's also LaunchELF. For years, we never had a rename function.
Finally, it is now compatible with other types of PS2s as well, like the DEX and PSX.
That's not actually all that was done, but I know nobody is interested in the stuff that goes on under the hood.
I mean, I actually took a few months to get it to have the new features that I wanted.
On a side note, it is not everyday that people realize that there is so much that goes on behind every project (not just mine, but PS2 development in general). So thanks for your understanding.
This is a console from an era, when the OS once offered much simpler services.
Thank you very much, really.
Yes, it is a shame.
Part of me might have been to blame though. Since I was much younger, I loved to explore and to make my own systems.
So I tended to prefer writing my own code, rather than using a 3rd party library. Well, it probably sounded like a great idea when I had 1-2 projects... but then came 2013, when I found that I had more than 4 projects to keep.
Coincidentally, I felt the same way. The many times when I wondered if I should have spent my time elsewhere, I always felt that there is something that will draw me back here.
If it's not because I feel like I have somebody to talk to, it's because the things here are more interesting than what really goes on everyday here. haha
I also realized through these months, why developers from back then sometimes say that this console is difficult to program. I used to think it was only the architecture that was the problem... but no, it's also because you had to do nearly everything yourself! Unlike a newer platform that has an OS that offers higher-level services, the kernels here only offer thread-management and other low-level services.
Font-rendering is a tricky subject, which was something that I have been struggling with since 2013 - when the first version of my reuable UIs came about. So the reason why my fonts always looked strange until this year, was because I cheated: I used the same amount of space between each character, to simplify the drawing process...
Thank you.
This is mainly for users of the SCPH-10000, SCPH-15000 and SCPH-18000.
Changelog for FMCB+FHDB v1.964:
- Replaced bad HDDLOAD.IRX (fixed booting of FHDB on SCPH-10000, SCPH-15000 & SCPH-18000).
- Increased maximum item count to 200, reduced maximum length to 128.
NEW: New changes that were made since the initial releases.
The HDDLOAD.IRX file is part of FMCB, which is used to locate the update on the HDD unit (I guess, you would use FHDB as the HDD update).
Downloads/Links
FMCB + FHDB + installer project page (downloads at bottom): https://sites.google.com/view/ysai187/home/projects/fmcbfhdb
For at least now, I won't add an option for sorting because I don't want to touch LaunchELF's code (which is used for the configurator).
EDIT: Replaced file.
EDIT: updated LaunchELF + USBHDFSD. The fix to USBHDFSD probably won't matter here, but just in case.
It's a limitation because it has to fit where the OSD will not use.
But as you wrote before, the current amount of space given to it is actually quite a lot. I have increased the maximum number of items to 256.
I'm not very sure what you mean here, sorry. These are all different projects.
What I meant was that the three versions of FMCB, are from the same tree. But that's only for FMCB.
If you mean to say that I could have done the same thing for my other projects, you are not wrong.
I did merge the standalone fsck tool back into HDDChecker's source code, although HDLGameUpdater might have to remain separate because HDLGameInstaller is just too big to make it work right.
I have my doubts. But I just haven't done anything yet because there will be too much work. Although I think it can be nice, since people do browse Github.
Some of these projects (HDLGameInstaller and PS2ESDL) have a few hundred versions. They've been in development for years, even before I wrote about them anywhere.
I really like the work you've done on FMCB. I suppose you are just not so interested in OSDSYS-Hacking.
Btw.; A lot more is possible (in that regard) via quite short code, tho'. Just thought, I'd mention it.
Honestly, no. I just found it challenging to make it work across all possible software revisions. The patterns can change, even if the compiler was changed.
Oh it's more than that. Recently, we found that the hardware itself might have various problems.
It just can't be made to have performance on its own, without issues.
Thanks for the encouragements and the insights.
After the occasional defacement cases of FMCB, Jimmi did add something for obfuscating the logo for FMCB v1.8c.
I went a step further, to make it more difficult to disassemble. Since it's closed source, that would be the only way to ensure that nobody would deface the logo to sell it as their own product.
But now that we're in 2018, I replaced it with the normal packer that I use for my other projects.
Ah, I see. Thanks
I'm sorry that I couldn't meet your expectations. Essentially, what the new versions of FMCB do, is whatever the previous ones do, but are more complete and reliable.
For example, it boots up faster because there is cleaner and shorter initialization code, copied from the Sony browsers. The old versions had a lot more stuff, I guess because ffgriever got his information from some other indirect way (i.e. logging from pcsx2 etc). The initialization code is also more correct and applicable to all PlayStation 2 consoles, instead of just the mainstream consoles.
Due to the contribution of an anonymous user, we were also able to be free of using a DVD Player KELF, so FMCB installations actually became smaller (62KB instead of 75KB).
There's also support for DVD Player updates, for all consoles (not just Japan, Europe and USA). While the original intent was for the SCPH-10000 and SCPH-15000 (which have no DVD player built in), the mechanism can be used to boot region-free DVD players as well.
Then we also had the USB modules updated. Initially it was just for reliability, but now they seem better at performance too. There's also LaunchELF. For years, we never had a rename function.
Finally, it is now compatible with other types of PS2s as well, like the DEX and PSX.
That's not actually all that was done, but I know nobody is interested in the stuff that goes on under the hood.
I mean, I actually took a few months to get it to have the new features that I wanted.
On a side note, it is not everyday that people realize that there is so much that goes on behind every project (not just mine, but PS2 development in general). So thanks for your understanding.
This is a console from an era, when the OS once offered much simpler services.
Thank you very much, really.
Yes, it is a shame.
Part of me might have been to blame though. Since I was much younger, I loved to explore and to make my own systems.
So I tended to prefer writing my own code, rather than using a 3rd party library. Well, it probably sounded like a great idea when I had 1-2 projects... but then came 2013, when I found that I had more than 4 projects to keep.
Coincidentally, I felt the same way. The many times when I wondered if I should have spent my time elsewhere, I always felt that there is something that will draw me back here.
If it's not because I feel like I have somebody to talk to, it's because the things here are more interesting than what really goes on everyday here. haha
I also realized through these months, why developers from back then sometimes say that this console is difficult to program. I used to think it was only the architecture that was the problem... but no, it's also because you had to do nearly everything yourself! Unlike a newer platform that has an OS that offers higher-level services, the kernels here only offer thread-management and other low-level services.
Font-rendering is a tricky subject, which was something that I have been struggling with since 2013 - when the first version of my reuable UIs came about. So the reason why my fonts always looked strange until this year, was because I cheated: I used the same amount of space between each character, to simplify the drawing process...
Whatever You will do, it doesn't matter. You are already part of the homebrew history with many great achievements. Without Your work, scene would be for sure crippled. Thanks for every single line of code to all the projects, even those which no one see (like i.e ps2sdk as average user even don't know about it's existence ^^"). I was tried join to You, but I ultimately failed and one day I realised that it is not my road, focusing more on the graphics.
In summary, I hope that now I fully free You from demons of the past.
Thank you.
Last edited by a moderator:
TatsumaYakoshi
Member
New release is having issues on my SCPH-79001 Install it like normal kept the config exited black screen for a long time, rebooted FMCB LOGO stuck, Formatted card, Installed again same, Tried 1.8 Release card works fine with that.
1.963 Worked before this as well.
1.963 Worked before this as well.
Last edited:
sp193
Developer
These few months, the stars have not been aligned for me.
@TnA wanted the number of items increased, but it so happened that there is also a limit to the space allocated for FMCB's configuration structure as well. 256 was too much, so I have reduced it to 200.
Then there was also this other change that I made to thread priorities, forgetting that FMCB doesn't update the screen like my other software do.
Please use the new file.
Last edited:
TatsumaYakoshi
Member
Everything is good now, thank you just didn't want other Users losing their install some people only have one Card.
I understand Mistakes happen in coding, Thank you for all the updates.
flavio90
Member
thank you for all your hard work
sp193
Developer
FMCB v1.965 Released (updated on 2018/11/03)
Changelog for v1.965 (as of 2018/11/03):
Tip for those who want to avoid a full reinstall:
If you had downloaded the previous release on 2018/10/27, you can simply copy the updated configurator from INSTALL/SYSCONF/FMCB_CFG.ELF and put it in the right place:
FMCB + FHDB project page: https://sites.google.com/view/ysai187/home/projects/fmcbfhdb
Changelog for v1.965 (as of 2018/11/03):
- Updated USBD & USBHDFSD for compatibility with devices that have only one Alternate Interface configuration.
- FMCB Configurator: fixed bug that prevented the PS2 from being switched off when there is no HDD installed.
- NEW 2018/10/27 - Updated USBHDFSD: fix bug that prevented correct reading & writing.
- NEW 2018/11/03 - FMCB Configurator: prevent potential crash if config file cannot be opened from device, by not closing the FD if it was not opened.
- NEW 2018/11/03 - FMCB Configurator: Avoid accessing the HDD unit, if possible.
Attempt to load configuration file from the device that it is booted from, before trying all other devices. When attempting to load USB modules, check memory cards before the HDD unit.
- Compiled with FreeType v2.9.1.
- Fixed UI bug when dealing with enums (not used for this project).
- Compiled with updated USBD & USBHDFSD modules. For compatibility with devices that have only one alternate interface configuration.
- NEW 2018/10/27 - Updated USBHDFSD: fix bug that prevented correct reading & writing.
- NEW 2018/11/03 - Updated LaunchELF.
- NEW 2018/11/03 - Added missing lines, in English, to translations that were not updated.
Tip for those who want to avoid a full reinstall:
If you had downloaded the previous release on 2018/10/27, you can simply copy the updated configurator from INSTALL/SYSCONF/FMCB_CFG.ELF and put it in the right place:
- Memory card: mc:/SYS-CONF/FMCB_CFG.ELF
- HDD unit: hdd0:__sysconf/FMCB/FMCB_CFG.ELF
FMCB + FHDB project page: https://sites.google.com/view/ysai187/home/projects/fmcbfhdb
Last edited by a moderator:
jolek
Senior Member
sp193
Developer
I have been replacing the file, to fix some minor issues related to performance or cosmetic defects. Nothing major. So even if the user does not move up, it is not an issue. Although moving up will mean that the user can enjoy the new changes.
Today, I replaced LaunchELF with a build that was based off commit ff91651
Today, I replaced LaunchELF with a build that was based off commit ff91651
Ooops, I forgot to reply here... Sorry!
(but I am sure, I actually did write a reply... I might have forgotten to actually send/post it!)
The FMCB-Configurator could do the sorting as well (it pretty much would only have to change the OSD-Item-String's number to be changed to the number/position of the new sorting.)!
It entirely depends on the kind of OSDSYS-Hack!
A function based on source (and doesn't need to be a 'visible' hack), usually is not so hard to make it compatible along different BOOT-ROM-Versions.
The biggest issue I see is, when someone tries to implement on of those more sophisticated manual OSDSYS-Hacks (mostly those which can be seen).
One example which comes to mind, which seems to be quite easy but is annoying, once you have to get it running on multiple BOOT-ROM (or more OSDSYS-)Versions:
The idea:
Idea of implementation:
The PS2SDK, or with which Sony-PS2SDK-version the OSDSYS was compiled?
If it is the secondary and you are referring to the 'patterns' FMCB looks up and patches, yes indeed!
But they can be 'traced' (even via PS2Dis and I think IDA can be used for it as well)!
Well... No... Back in the day I said Padawan (Jedi)!
I certainly love the 'Über-Compatibility' of FMCB... It's great to see it working with almost all features, on almost every MagicGate supporting PS2-Variation (CEX, DEX, PSX, etc.)!
Maybe @7o7o just had the wrong expectations?!
It's great to have a more universal one nowadays.
It also enables/-d us, to create KELFs with varying sizes (so it could be bigger as well, but if I remember correctly, there still was a limit at a certain point... but that would not matter for the Loader/Payload).
I think the regional flagging profited from it, but was still something else.
The majority (like most users), probably not... but some persons around here would certainly like to (know)!
The function could be moved to another memory-location and 1Item uses 17Byte (atleast in 1.8), if I remember correctly.
I will look up the function and post it tomorrow. I've got a lot to do for the next 9 hours...
(but I am sure, I actually did write a reply... I might have forgotten to actually send/post it!)
No problem! I certainly don't need it myself! I just mentioned how it could be implemented.
The FMCB-Configurator could do the sorting as well (it pretty much would only have to change the OSD-Item-String's number to be changed to the number/position of the new sorting.)!
Yes, indeed!
Well, as we know now that was too much... 200 is sufficient, tho'!
Your following explaination does describe, what I meant, so you got me right!
Well, I think in this way it might be a bit easier to update those tools, which share some common/same recourses... Great, that you already did that for some of your projects!
Well, yes the initial commit also would be a final commit and we couldn't see the changes throughout the development, but GitHub is a great recourse for projects and sources and git makes some stuff sooooo easy. It's just nice and more of your projects on it, would be even nicer, IMO!
Yes, I can relate to that...
It entirely depends on the kind of OSDSYS-Hack!
A function based on source (and doesn't need to be a 'visible' hack), usually is not so hard to make it compatible along different BOOT-ROM-Versions.
The biggest issue I see is, when someone tries to implement on of those more sophisticated manual OSDSYS-Hacks (mostly those which can be seen).
One example which comes to mind, which seems to be quite easy but is annoying, once you have to get it running on multiple BOOT-ROM (or more OSDSYS-)Versions:
The idea:
- Show the FMCB-(Loader/Payload-)Version in the 'Version'-Submenu
- The same for the ROMVER-String...
Idea of implementation:
- 'rebuild' OSDSYS-Version-Submenu just like it is done for the main-screen of the OSDSYS (where 'Browser' and 'Systemconfiguration' is shown) [~I am gonna place the function names here later...~]... {I think this is, what you are referring to with the 'patterns'} This is the most annoying stuff IMO, because this essentially becomes the 'glue' between the different OSDSYS-Versions and all those fancy functions of the Payload (hacked OSDSYS, etc.). One Version might expect another order of functions in MIPS-ASM. One thing which comes to my mind (I am quite sure that's one of the issues that occurred back in the days.): a register could be used on one but not another PS2-Model, or simply the placing of the JAL (That's just an example... I mean the order of the instructions) works on one but not another version.
- For ROMVER the string needs to be read either during init, or before the OSDSYS gets patched and of course that string has to be passed to the according patching-function...
- As for %VER%... Well, I don't know if it is a global constant or variable, or if it is locally within the CNF-Parser... (with an exception trigger, if the CNF Parser reads '%VER%). Obviously this function (the version-submenu-hack) would not need to 'get in contact'/use the CNF-Parser... (but it still could get it from there, possibly)
I am not 100% certain, what you are referring to (in this case).
The PS2SDK, or with which Sony-PS2SDK-version the OSDSYS was compiled?
If it is the secondary and you are referring to the 'patterns' FMCB looks up and patches, yes indeed!
But they can be 'traced' (even via PS2Dis and I think IDA can be used for it as well)!
Oh! I might have missed that one!
No problem. For all of your contributions in this scene, you deserve more IMO.
Aaaah, alright!
It seems he hasn't tried it any further.
Well, I am certainly quite happy and my expectations have been met! I knew (back in 2008/2009 and afterwards) you were/are Neo and could bend the matrix!
Well... No... Back in the day I said Padawan (Jedi)!
I certainly love the 'Über-Compatibility' of FMCB... It's great to see it working with almost all features, on almost every MagicGate supporting PS2-Variation (CEX, DEX, PSX, etc.)!
Maybe @7o7o just had the wrong expectations?!
If I remember correctly, ffgriever dumped some cdvd-related RAM-Portions (CDVD-Registers?) and re-implemented it back manually. This in the beginning caused some troubles with various models, because some were using other 'patterns'/instructions/orders.
Indeed! Well, FMCB 1.8 was the first to even have a quite complete (but still not perfect) system-initialization. It was one of the reasons, why I said that 1.8 is intended to be 'rock solid' (prior to the release)!
It's great to have a more universal one nowadays.
You've got to love the anonymous people... :P
It also enables/-d us, to create KELFs with varying sizes (so it could be bigger as well, but if I remember correctly, there still was a limit at a certain point... but that would not matter for the Loader/Payload).
I think the regional flagging profited from it, but was still something else.
That's another neat thing! One more limitation lifted (in conjunction with the DVD-Player-Hacks discussed at assemblergames.com)!
All these things are great and you made a lot other projects as well, so not meeting someone's expectations is nothing to worry about, I think.
Nobody? Nah, not true!
The majority (like most users), probably not... but some persons around here would certainly like to (know)!
Not only for this, but for other projects he had done as well... It would have been soo cool, if he would have posted the sources of any of his projects... :-/
Ooooh! The cause of this (probably) is the pointer-array overflowing. The function for this is... (I will edit the post later and add the name.)
The function could be moved to another memory-location and 1Item uses 17Byte (atleast in 1.8), if I remember correctly.
I will look up the function and post it tomorrow. I've got a lot to do for the next 9 hours...
Last edited:
I think I found it!
It's probably the struct 'osdsys_settings', which is overflowing into another region, once it grows too big (thus not allowing 256 or more items)... --> typedef struct {~} osdsys_settings;
Changing it's Memorylocation would 'fix' that '(non-)issue', I suppose!
I will add the OSD Hack-related functions I meant and which can be reused in a similar way to rebuild another 'sub-menu', once I find it.
I've got to take a nap. It's past 3AM here...
It's probably the struct 'osdsys_settings', which is overflowing into another region, once it grows too big (thus not allowing 256 or more items)... --> typedef struct {~} osdsys_settings;
Changing it's Memorylocation would 'fix' that '(non-)issue', I suppose!
I will add the OSD Hack-related functions I meant and which can be reused in a similar way to rebuild another 'sub-menu', once I find it.
I've got to take a nap. It's past 3AM here...
SneakyKreiger
Member
Just curious if anyone has an issue with the v1.965 not actually reading game saves from either slots. I was tinking with some game saves the other day and noted that neither of them would appear to load or even read. So i pulled the FMCB card out. And put the other card in , and my game save appeared. Would this be a issue of the older commit?!
SneakyKreiger
Member
Well i believe its something up with my FMCB card or maybe a setting or something tbh i'm not so sure. i do know that when the card isn't in the MC0 slot , the save will read prefectly. But when my FMCB card is in that same slot the save won't work. idk why. I've even tryed coping/moving my save to the MC0 slot. and still it doesn't show that my card is has a game save on it.Not sure if it will help but in detail, The save is for a ps1 game on a PS2 FMCB MG MC card.I had it on a PS1 card in MC1 and it still acted as if the card or save wasn't inserted.
sp193
Developer
Sorry, but I still don't understand. What won't read it?
If you were referring to a PlayStation game, PS2 cards are not supported by PlayStation games. You may back up PlayStation saves onto a PS2 card, but the same save on the PS2 card will not be readable by the PlayStation game.
Some ways of hacking the OSDSYS:
Method 1 - Manual hacking of the OSDSYS
I am just mentioning it here for the sake of completeness. Not that those Infos get lost in the abyss.
I'm posting those functions I mentioned and have not yet named, later.
Method 1 - Manual hacking of the OSDSYS
- Usually is the annoying stuff, which might have different patterns which need to be patched.
- Implemented via MIPS-ASM and only needed for specific stuff
- This essentially becomes the 'glue' between the 'Method 2'-Hacks, which are quite more universal and the hacked OSDSYS. This is a base...
- Some things like the scrolling menu are based on normal source and functions, but partially on manual hacking as well...
- Things like 'call_from_osdsys' (or similar written) can call external code (send some info to another custom thread, which reacts upon it) and technically the idea could be expanded upon and used as a third method for hacking the OSDSYS during runtime!
I am just mentioning it here for the sake of completeness. Not that those Infos get lost in the abyss.
I'm posting those functions I mentioned and have not yet named, later.
Last edited:
Some crucial features for the FMCB/FHDB 2.0-Payload (IMO):
- the Version-Submenu should show the FMCB-Version (and preferably the ROMVER-String as well)
- argument-passing to ELFs (also via the CNF), which can be reused in various ways... Some Homebrew-Apps already do support args (PS2PSXe, POPStarter etc.)! If FMCB/FHDB and some of the prominent APPS could have support for some useful args, it could be of use.
Last edited:
sp193
Developer
FMCB already prints its version number. But there is no reason to print ROMVER as all ROMs provide the same basic modules. If knowing more about your PS2 is what you want, there exists PS2Ident.
Arguments are for passing information between distinct programs. There would have to be some reason to do that, before anything can be standardized.
Arguments are for passing information between distinct programs. There would have to be some reason to do that, before anything can be standardized.
Yes, but it would match much better into the Version-Menu, then to show it in the Main-Menu and those Fakers out there who would use FMCB 1.7 or say and claim it to be 2.0 would get exposed...
Oh, there is sooo much stuff, which could be made with it! Things like directly starting a ROM, or directly jumping into wLE's HDD Manager and if you exit it, you are not in the Main-Menu of uLE, but back in the hacked OSDSYS, etc.
Argument-Support probably would be even more useful for OPL, especially how more emulators would support it.
For example if Retroarch would support args and OPL as well, OPL's GUI (specifically Apps-Page/-s) could be reused as Emu-GUI as well.
The possibilities are not limitless, but still very interesting. On Linux it's quite normal to support argument-passing... I ever would have loved to see that on a PS2 as well.
Oh, there is sooo much stuff, which could be made with it! Things like directly starting a ROM, or directly jumping into wLE's HDD Manager and if you exit it, you are not in the Main-Menu of uLE, but back in the hacked OSDSYS, etc.
Argument-Support probably would be even more useful for OPL, especially how more emulators would support it.
For example if Retroarch would support args and OPL as well, OPL's GUI (specifically Apps-Page/-s) could be reused as Emu-GUI as well.
The possibilities are not limitless, but still very interesting. On Linux it's quite normal to support argument-passing... I ever would have loved to see that on a PS2 as well.
Similar threads
-
Welcome to PSX-Place (v3) - Upgrade Now Complete !!!- Started by STLcardsWS
- Replies: 33
-
-
PS3 PS3 Firmware 4.93 - Update is Live! (CFW and HFW Released)- Started by LuanTeles
- Replies: 38
-
PS2 Free McTuna! OpenTuna Installers with Free MCBoots via PS2BBL!- Started by Ripto
- Replies: 26