Help with patched Sony ATAD.IRX (not looking for download)

[LocalH]

I am attempting to add basic HDD support to Guitar Hero 80s for the possible use of making customs easier to use (instead of building a new game ISO and installing it, I can then just change out the necessary files on the HDD with new ones). However, I'm not sure on the path naming from that end of things. I know when you make a new PFS partition with uLE, it adds a "+" to the front of the filename, my question is do I have to reference that "+" in the pathname that I pass to the PFS driver? Also I know that the official drivers use pfs0: if I'm not mistaken?

I have the following Sony IRX modules that I believe are necessary for HDD support:

1) ATAD.IRX (patched to allow use of non-Sony HDD)
2) DEV9.IRX (obvious)
3) HDD.IRX (also obvious)
4) PFS.IRX (I would assume this is necessary to actually access a partition)

I ripped these files (including unpatched ATAD) from SF Alpha Anthology, patched the ATAD myself, and am not 100% sure if I need other files.

Alternately: I'm reading that OPL (at least for the purpose of locating apps and I think configs/VMC) mounts hdd0:+OPL as pfs0:. Does this persist such that game code can utilize it? I'll bung all my custom tracks in hdd0:+OPL if that makes it easier

[sp193]

I am attempting to add basic HDD support to Guitar Hero 80s for the possible use of making customs easier to use (instead of building a new game ISO and installing it, I can then just change out the necessary files on the HDD with new ones).

If the game doesn't have HDD support built into it's main executable, you cannot just stick the HDD support IRX modules into it and expect the game to be able to access the HDD without additional hackery.

However, I'm not sure on the path naming from that end of things. I know when you make a new PFS partition with uLE, it adds a "+" to the front of the filename, my question is do I have to reference that "+" in the pathname that I pass to the PFS driver? Also I know that the official drivers use pfs0: if I'm not mistaken?

Yes. Actually, I don't remember that it was required for Sony partitions to have a "+" character at the starting of the partition's name... so it's probably a homebrew thing.

I have the following Sony IRX modules that I believe are necessary for HDD support:

1) ATAD.IRX (patched to allow use of non-Sony HDD)
2) DEV9.IRX (obvious)
3) HDD.IRX (also obvious)
4) PFS.IRX (I would assume this is necessary to actually access a partition)

I ripped these files (including unpatched ATAD) from SF Alpha Anthology, patched the ATAD myself, and am not 100% sure if I need other files.

That should be all you need, but you need get the game to access the files on the HDD. ;)
(Unless you are telling me that this Guitar Hero game has code for accessing the HDD, but was just not in use).

Alternately: I'm reading that OPL (at least for the purpose of locating apps and I think configs/VMC) mounts hdd0:+OPL as pfs0:. Does this persist such that game code can utilize it? I'll bung all my custom tracks in hdd0:+OPL if that makes it easier

No.

[LocalH]

Well, I was hoping that with the combination of drivers, accessing the proper file path would work sort of "on its own". I had a similar idea to try to use USB instead, but don't have any games that can access a USB drive with official drivers, and I wasn't even about to try homebrew drivers as I figured there was exactly a 0% chance of it working.

My thought was, GH80s has a configuration file called gh2.dtb (since it's based off the GH2 codebase) that, when decrypted and detokenized, instructs the game program to load specified IRX drivers (in fact, a couple are set to load only when _SHIP is not defined, for debugging purposes):

(iop_modules (iop/scrtchpd.irx)
(iop/sio2man.irx)
(iop/mcman.irx)
(iop/mcserv.irx)

#ifdef _SHIP
(iop/usbd.irx FALSE)
(iop/usbkb.irx FALSE)

#else
(iop/usbd.irx)
(iop/usbkb.irx
"keybd=1"
"debug=0")

#endif
(iop/padman.irx)
(iop/msifrpc.irx)

#ifdef _SHIP
(iop/mtapman.irx FALSE)

#else
(iop/mtapman.irx)

#endif
(iop/libsd.irx)
(iop/sdrdrv.irx)
(iop/cdvdstm.irx)
# (iop/dev9.irx) # these four lines not present in the original, added by me
# (iop/hdd.irx)
# (iop/atad.irx)
# (iop/pfs.irx))

#ifdef _SHIP
(keyboard (disable TRUE))
(multitap (disable TRUE))

#endif

I'm not sure on the development timetable, but I know GH80s was released a few months after GH2 for the 360 (which did have support from loading songs elsewhere than the main game disc) and was hoping that some sort of generic support was present that wasn't present in GH2 PS2 that would allow this to work. I'm still going to try anyway, worst case scenario the game fails to boot, best case scenario everything works like i want it to.

[SilverBull]

Well, I was hoping that with the combination of drivers, accessing the proper file path would work sort of "on its own". I had a similar idea to try to use USB instead, but don't have any games that can access a USB drive with official drivers, and I wasn't even about to try homebrew drivers as I figured there was exactly a 0% chance of it working.

Even if all necessary drivers are loaded, you would still need to mount the partition. In homebrew code using the fileXio module, you could use something like fileXioMount("pfs0:", "hdd0:yourPartitionNameHere", 0). The SCE fileIo library contains a sceMount function, but it is unlikely that GH calls it anywhere if it doesn't already contain HDD support. However, chances are the routine is still present somewhere along the other file I/O client code.

My thought was, GH80s has a configuration file called gh2.dtb (since it's based off the GH2 codebase) that, when decrypted and detokenized, instructs the game program to load specified IRX drivers (in fact, a couple are set to load only when _SHIP is not defined, for debugging purposes):

I'm not sure on the development timetable, but I know GH80s was released a few months after GH2 for the 360 (which did have support from loading songs elsewhere than the main game disc) and was hoping that some sort of generic support was present that wasn't present in GH2 PS2 that would allow this to work. I'm still going to try anyway, worst case scenario the game fails to boot, best case scenario everything works like i want it to.

If there are no additional checks present (e.g., some checksum protecting that file from being tampered with), modifying the configuration file could actually work. However, you won't get the program magically using the new device.

I am attempting to add basic HDD support to Guitar Hero 80s for the possible use of making customs easier to use (instead of building a new game ISO and installing it, I can then just change out the necessary files on the HDD with new ones). However, I'm not sure on the path naming from that end of things. I know when you make a new PFS partition with uLE, it adds a "+" to the front of the filename, my question is do I have to reference that "+" in the pathname that I pass to the PFS driver? Also I know that the official drivers use pfs0: if I'm not mistaken?

"pfs0" is just the first mountpoint. How many there are depends on which parameters you pass to pfs.irx. You can use "pfs1" and so on if you like and the driver has been configured to provide them.

There is a naming convention that the names of all application partitions start with a plus sign. I think Sony required this in the TRC, but I could be mistaken here. Anyway, that plus sign is a valid character in a partition name, and you need to pass the full partition name, including the plus sign if present, to sceMount.

I have the following Sony IRX modules that I believe are necessary for HDD support:

1) ATAD.IRX (patched to allow use of non-Sony HDD)
2) DEV9.IRX (obvious)
3) HDD.IRX (also obvious)
4) PFS.IRX (I would assume this is necessary to actually access a partition)

Your load order in the configuration file s wrong. Use this:

1. DEV9 (low-level DEV9 interface)
2. ATAD (low-level ATA driver via DEV9)
3. HDD (expose ATA HDDs as block device)
4. PFS (file system)

I ripped these files (including unpatched ATAD) from SF Alpha Anthology, patched the ATAD myself, and am not 100% sure if I need other files.

The drivers should work if they are loaded in the correct order. There are no dependencies to other libraries (besides the ones that are already loaded as part of the IOP kernel). However, I strongly suggest you make sure your "donor" game has been compiled with the exact same version of the PS2 SDK.

Alternately: I'm reading that OPL (at least for the purpose of locating apps and I think configs/VMC) mounts hdd0:+OPL as pfs0:. Does this persist such that game code can utilize it? I'll bung all my custom tracks in hdd0:+OPL if that makes it easier

I haven't looked at the OPL code for a long time, but it would surprise me if this mount was still active when the actual game is running. The reason is that IOP memory is extremely scarce, so they try to get the OPL core as small as possible. And including a full APA and PFS driver certainly is not required; they can simply remember which LSN ranges comprise the CDVD image, then access that part of the HDD directly without going through the APA layer. For the same reason, OPL's game partitions also do not need (and I'd also bet they do not have) PFS structures. Its a little different for USB drives, but you can play similar tricks there as well. I'm sure sp193 can provide more information .

[richi902]

official sony partitions are requierd to use the "PP." prefix follow by the title-id/disc-id, then some random stuff choosen by the developer,
example "PP.SLPM-62356.PAT0.DATA7" <<winning eleven 7 partition, according the sony sdk documentation.

the "+" is from the homebrew sdk, propably to prevent to be sued from sony :p.

[LocalH]

If there are no additional checks present (e.g., some checksum protecting that file from being tampered with), modifying the configuration file could actually work. However, you won't get the program magically using the new device.

AFAIK, there are no checksums that aren't already taken care of by the available tools for handling the HMX GH/RB file formats (especially when concerning such an old version of the codebase as GH2/80s). I have successfully modified other configuration files, including some of those which handle some of the UI flow, as well as successfully changing the game ID for the purposes of having multiple co-existing saves for use with custom game images. Of course, this is a bit more low level than those type of changes.

There is a naming convention that the names of all application partitions start with a plus sign. I think Sony required this in the TRC, but I could be mistaken here. Anyway, that plus sign is a valid character in a partition name, and you need to pass the full partition name, including the plus sign if present, to sceMount.

Good to know that basically whatever the partition is named is how it needs to be referenced. I was thinking this was the case, but wanted to confirm.

Your load order in the configuration file s wrong. Use this:

1. DEV9 (low-level DEV9 interface)
2. ATAD (low-level ATA driver via DEV9)
3. HDD (expose ATA HDDs as block device)
4. PFS (file system)

The drivers should work if they are loaded in the correct order. There are no dependencies to other libraries (besides the ones that are already loaded as part of the IOP kernel). However, I strongly suggest you make sure your "donor" game has been compiled with the exact same version of the PS2 SDK.

I almost had the order right, just needed to swap ATAD and HDD. How would one determine which version of the SDK the game was compiled with? Would it be sufficient to check the IOPRP image itself? GH80s has IOPRP300.IMG (2003/10/22) while SFAA has IOPRP310.IMG (2005/11/24). Should I basically locate a game with HDD support that uses IOPRP300?

I haven't looked at the OPL code for a long time, but it would surprise me if this mount was still active when the actual game is running. The reason is that IOP memory is extremely scarce, so they try to get the OPL core as small as possible. And including a full APA and PFS driver certainly is not required; they can simply remember which LSN ranges comprise the CDVD image, then access that part of the HDD directly without going through the APA layer. For the same reason, OPL's game partitions also do not need (and I'd also bet they do not have) PFS structures. Its a little different for USB drives, but you can play similar tricks there as well. I'm sure sp193 can provide more information .

I pretty much figured as much, if anything I figured that any mountpoint access would be only internal to OPL itself (for VMC access, etc) and not be exposed to the running game. Just wanted to confirm.

Also, just to confirm - using the official drivers, a partition must be mounted to pfsX: via sceMount(), and not directly accessed as within uLE as hdd0:blah, correct?

Good to know that this has a slight chance of working if I can hack it out, although I realize I may be in over my head. Still, worst case scenario I've wasted some time and I have enough time to waste, so to me it's worth trying.

official sony partitions are requierd to use the "PP." prefix follow by the title-id/disc-id, then some random stuff choosen by the developer,
example "PP.SLPM-62356.PAT0.DATA7" <<winning eleven 7 partition, according the sony sdk documentation.

Do you know if that's a technical restriction on the part of the drivers, or just a Sony requirement to pass?

Also, one more question if anyone knows the answer. Will OPL's access to the HDD impede the ability of the driver to load and access the HDD at the same time? If so, I'll just run my hacked GH image from USB, since the brunt of the data would be on the HDD anyway.

[sp193]

I almost had the order right, just needed to swap ATAD and HDD. How would one determine which version of the SDK the game was compiled with? Would it be sufficient to check the IOPRP image itself? GH80s has IOPRP300.IMG (2003/10/22) while SFAA has IOPRP310.IMG (2005/11/24). Should I basically locate a game with HDD support that uses IOPRP300?

You can determine the SDK version roughly by looking at the version of the IOPRP image that it uses. IOPRP300.IMG -> SDK v3.0.0, IOPRP24.IMG -> SDK v2.4.0 etc.

Also, just to confirm - using the official drivers, a partition must be mounted to pfsX: via sceMount(), and not directly accessed as within uLE as hdd0:blah, correct?

The same thing applies to when you use homebrew drivers. It's a requirement by design.

hdd0: is the raw HDD device, much like how sda: and hda: are raw block devices to Linux. It contains lots of partitions, all of which must be mounted first before they can be used.

Good to know that this has a slight chance of working if I can hack it out, although I realize I may be in over my head. Still, worst case scenario I've wasted some time and I have enough time to waste, so to me it's worth trying.

Without experimentation, you cannot reach greater heights. :)

Do you know if that's a technical restriction on the part of the drivers, or just a Sony requirement to pass?

It's Sony's requirements. But if you don't have "PP" or "PS" as the first section of the partition's name, it might be treated as "corrupted data" in at least the PSBBN dashboard.

The format of the partition name should be roughly like this (According to the Sony SDK v3.0.2):
<PP/PS>.<Product ID>.title.label

The entire name must not exceed 32 characters, and must consist of only alphanumeric characters and underscores.

PP -> Partition (Primary)
PS -> Partition (Slave/Secondary/child)

All child partitions must have a valid primary partition of the same product ID.

Also, one more question if anyone knows the answer. Will OPL's access to the HDD impede the ability of the driver to load and access the HDD at the same time? If so, I'll just run my hacked GH image from USB, since the brunt of the data would be on the HDD anyway.

It should not... at least, from my understanding of the design of OPL, it shouldn't.....

[LocalH]

You can determine the SDK version roughly by looking at the version of the IOPRP image that it uses. IOPRP300.IMG -> SDK v3.0.0, IOPRP24.IMG -> SDK v2.4.0 etc.

Good to know. I'll go through my games and see if any of them have the HDD drivers and IOPRP300.IMG.

The same thing applies to when you use homebrew drivers. It's a requirement by design.

hdd0: is the raw HDD device, much like how sda: and hda: are raw block devices to Linux. It contains lots of partitions, all of which must be mounted first before they can be used.

So uLE is "special" in how it references hdd0: directly in file paths in a user-visible way. Also good to know.

It's Sony's requirements. But if you don't have "PP" or "PS" as the first section of the partition's name, it might be treated as "corrupted data" in at least the PSBBN dashboard.

The format of the partition name should be roughly like this (According to the Sony SDK v3.0.2):
<PP/PS>.<Product ID>.title.label

The entire name must not exceed 32 characters, and must consist of only alphanumeric characters and underscores.

PP -> Partition (Primary)
PS -> Partition (Slave/Secondary/child)

All child partitions must have a valid primary partition of the same product ID.

Also good to know. I don't run either PSBBN or HDDOSD (non-Sony drive without modchip) so I don't guess that really matters for me, I might name it officially just for the hell of it.

It should not... at least, from my understanding of the design of OPL, it shouldn't.....

I had been reading an old thread (specifically regarding SFAA actually) elsewhere that said that the HDD driver would load, but that it wouldn't be able to mount any partitions. Not sure if that was accurate or not, though.

[richi902]

you can still use the decrypted hdd-osd which is ATAD-patched :p

[LocalH]

Yeah, I've read about that but haven't spent the time to get it going. Maybe someday :P