forums.ps2dev.org

My question is:
In windows or linux I can load files form a relative path (./ or cimple empty path). So, if I run the program from c:\appXX it will look for files inside that folder.

I want to do the same for playstation 2, because my project will use graphics from anyone (users will be able to use their own graphics), but how do I do that?

Should I check the complete path somehow and see the unit (mass:, cdfs:, mc0:) and load the apropriate IRX, or there is a simpler method for this?

Thanks in advancem and sorry if this question was already answered or is dumb :)

Yeah, you should check the path it was executed from, and load the appropriate module or modules. I think uLaunchElf's main() function checks for every known launching method, so you could look in its source for the list of devices.

Just a quick question. I was looking at the forum for answers, but did not something more clear about running from CD. Is there a way to access cdrom: like I do for mass:?

I found some dvd libs and methods, but those require to use xio file handling functions. As my code is meant to be portable, I want to keep using the regular fopen/fread/fwrite to not include a lot of IFDEFs or messing with the SDL code (that have some file handling in too)....

I am using ps2doom v1041 source as base (it is an easy one to understand, uLE is more complicated), but is seems to lack "run from cdrom" capabilities.

protomank wrote:Just a quick question. I was looking at the forum for answers, but did not something more clear about running from CD. Is there a way to access cdrom: like I do for mass:?

Once I did an quick example on how to load files from cdrom: device and put it into my 4shared folder (http://www.4shared.com/dir/5927899/2830 ... aring.html). It's still there.

You saved my sanity! I was looking for cdvd.irx for more than a hour now :)

EDIT: Funny enought, if I run my elf from mass, and force all files to load from cdfs, it works. If I just boot the same elf from the cdrom, it freezes in the loading of files.
Looks like I'll have to buy a lot of CDs tomorow... :-P

protomank wrote:You saved my sanity! I was looking for cdvd.irx for more than a hour now :)

EDIT: Funny enought, if I run my elf from mass, and force all files to load from cdfs, it works. If I just boot the same elf from the cdrom, it freezes in the loading of files.
Looks like I'll have to buy a lot of CDs tomorow... :-P

A hint to avoid wasting CDs : keep your experiment code simple and test it with pcsx2.

PCSXE2 does not run on my computer, my onboard video card is not enought and the motherboard do not have a pci express slot.

But I fixed it, added some loading information (good for the user also) and I believe the problem was that some SDL calls I was using did not released the file handler, so when I changed it, the program ran from the cdrom, thanks to your code :)

Now I am just missing HDD support, that I still need more information, because I do not have one (I own a PS2 slim) and a friend of mine that have one, told me each game is a partition and the filesystem is kind of strange.

protomank wrote:Now I am just missing HDD support, that I still need more information, because I do not have one (I own a PS2 slim) and a friend of mine that have one, told me each game is a partition and the filesystem is kind of strange.

The PS2 HDD filesystem is split into two separate logical device groups.

One device group can only have a single member, this being the device "hdd0:", which is the physical HDD connected as master IDE unit. If the hardware design fully supported an IDE slave unit, that would have become "hdd1:", but that would demand extensive hardware modifications.

Through the "hdd0:" device driver it is possible to access some directly drive-related operations, including raw sector reading and writing, and other operations related to partition control, of course also including the reading of the list of existing partitions.

The other device group is for a set of virtual mountpoint devices using the "pfs" prefix, resulting in full names like "pfs0:", "pfs1:" and so on. These names do not represent any specific physical devices, but instead represent only the contents of some partition from the "hdd0:" device that has been 'mounted' onto that pfs link.

So the meaning of a specific full pathname like "pfs1:/somefolder1/somefolder2/somefile.ext" will depend both on which partition is currently 'mounted' in the mountpoint "pfs1", and on the contents of that partition.

This adds lots of complexity for cases where a launched program needs to find its own location, as there is no system function available for this purpose, and the program launch arguments only pass the PFS path, which does not contain the name of the partition that was mounted at the time of the launch (no longer mounted after reinitializing drivers as part of an application init).

Even so, the PFS-based filesystem is the only one which allows normal file handling on a PS2 IDE HDD, both for data and program files, as used by normal PS2 programs both of commercial and homebrew design. In addition to this filesystem, PS2 Linux can also allow other filesystems to be used but those are then not compatible with other PS2 software.

As your friend mentioned, HDLoader does not use any normal file handling for installed games, which are instead stored with a separate partition for each complete game disc. That partition is then accessed through the CDVD emulation driver of HDLoader (or the homebrew "Open PS2 Loader") as if the sectors of that HDD partition were in fact sectors of the original game DVD disc.

One odd consequence of this usage, which sharply contrasts to any normal HDD usage of a PC, is that a PS2 HDD used for HDLoader frequently has a very large number of partitions, sometimes several hundred... But personally I try to avoid having that many as it leads to considerable delay whenever needing to renew the game list files.

Best regards: dlanor

Thanks for your explanation dlenor, it surely will help.