PS2 modules and such

Krah

Developer
Trying to work with some old source code for a bit of fun and it uses fio functions, I know fileXio has its own modules that need to be loaded and init...

Does fio have its own module I should be loading?

At some point I might just try change all fio to fileXio but for now I'm just curious
 
There is a standard set of modules that is always loaded. These modules are specified by IOPBTCONF.
FILEIO (The file I/O RPC service) is one of them. These modules are also replaceable by the software, by rebooting the IOP with an image containing the substitute modules.

Rightfully, we would be doing that, but perhaps it was not done because the homebrew SDK lacked the functions for rebooting the IOP that way. fileXio isn't a full replacement module. It hooks onto the old FILEIO module to steal its module list, and it also provides access to the newer functions.

fileXio is also meant to be used with iomanX, which is also a homebrew add-on module that complements IOMAN (which it should rightfully replace).
 
Are the X-Modules supported on every version (PS2-Model)?

Another problem I ought to remember is, that these modules had some dependencies on the Homebrew-PS2SDK.

The PS2SDK is still partially 'patched up' (some patches to COP0 and sbv are necessary tho') to even compile and some functions can not be used/accessed that easily. It also results in us not being able to use the newest tools (GCC, etc.) and continually update them easily (or why we have to manually port more things to get things like newlib running).

@sp193 and @uyjulian or @fjtruji probably could give a more detailed explanation, why and what is the root-cause of this. I am however not sure, if it is directly related.
 
Works fine on pcsx2 but not real hardware.
Starting to think it's cause I'm not resetting the IOP before loading modules, there's a nice example in your link there to do it without using an IOPRP img which is handy as I'm not exactly sure how to make one and can't find any info about it.

Cheers for the link.
 
I'm having a strange encounter with fileXioRemove() it removes the file but leaves a blank directory in its place (with the same filename), and trying to then delete this folder with fileXioRmdir() replaces the original file.

anyone else ever run into his or have an idea of a possible cause/solution?

@Based_Skid @sp193
 
To be honest with you no I haven't encountered an issue like that.

But I am having an issue with usbhdfsd and my drive keeps getting corrupted I've tried several different drives. Anytime I try to read or write a file. It also seems to be crashing the console when loadExecPS2 is called.
 
Are you sure you were using fileXioRemove() and not fioRemove()? The former will call functions from the home brew fileXio module, while the latter will call functions from FILEIO.
However, since we use the old version of FILEIO from the boot ROM, fioRemove will normally incurr a bug that causes mkdir() to be called after remove().

If you must use the original FILEIO for whatever reason, run the sbv_patch_fileio() patch first.
This will also fix fioGetstat() and fioDread().

You should always reboot the IOP when your program starts. It is because we have no standard on who reboots the IOP, and the IOP may have incompatible modules loaded.
 
Are you sure you were using fileXioRemove() and not fioRemove()? The former will call functions from the home brew fileXio module, while the latter will call functions from FILEIO.
However, since we use the old version of FILEIO from the boot ROM, fioRemove will normally incurr a bug that causes mkdir() to be called after remove().

If you must use the original FILEIO for whatever reason, run the sbv_patch_fileio() patch first.
This will also fix fioGetstat() and fioDread().

You should always reboot the IOP when your program starts. It is because we have no standard on who reboots the IOP, and the IOP may have incompatible modules loaded.
You're right I was using fioRemove() ... Didn't think it'd make much difference but it's all starting to make sense, that's why there are modules on game discs.. updated modules.

The only reason I've been hesitant to update the modules in the app is that when I used the latest USB modules it resulted in the ELF taking longer to initialize, might be time to bite the bullet and just update everything.

Thanks for your insights
 
Back
Top