UmdImageCreator

[Edness]

Nice, looks like raw PFI data is written at 0x24.


Info derived from your hexdumps:

Code: Select all

800001E00003000000045D5F00000000
Layer 0 - Size: 89440 sectors, 183173120 bytes
Total size: 89440 sectors, 183173120 bytes

Code: Select all

800031E00003000000FCAB2F0009C0BF
Layer 0 - Size: 442560 sectors, 906362880 bytes
Layer 1 - Size: 420848 sectors, 861896704 bytes
Total size: 863408 sectors, 1768259584 bytes

Code: Select all

800001E000030000000507BF00000000
Layer 0 - Size: 133056 sectors, 272498688 bytes
Total size: 133056 sectors, 272498688 bytes

I wonder if the value written at 0x08 determines how much data to write into the 2nd array.  What happens if you write, say, 32 in there like in the 2nd function, or better yet 16 which should cut off the last 4 bytes of the PFI on the DL disc.

[sarami]

Changed to 16.

Code: Select all

bufStruct[8] = 16;

The result is same as you expected. Disc is Dissidia 012.

Code: Select all

 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 10 00 00 80 00 31 E0 00 03 00 00 00 FC AB 2F
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

EDIT:
PFI of DVD is 2048 bytes. According to Ecma-365, it's the same for UMD, but byte 19 - 2047 of UMD are all zeros. That is why dumping 18 bytes is sufficient for preservation.

[Edness]

I suppose if you set the dump size to 0x1004, it'd dump the full PFI followed by the DMI?  Although DMI is often empty, so maybe it won't be easy to tell, dunno.

[sarami]

I tried "bufStruct[9] = 8" (0x800). Function call succeed, but hardware hanged up.
And tried "bufStruct[9] = 16" (0x1000). Function call failed.

By the way, if possible, could you research sceUmdExecReadDiscInfoCmd and sceUmdExecGetConfigurationCmd? Both are also SCSI-like fuctions.

[Edness]

Yeah, I can check it out either during the weekend or on Monday (or just next week in general.)  Depends on IRL stuff.

[Edness]

Unrelated, I know you've already confirmed the multi-partition UMD GAME+MOVIE discs are most likely correct size in your original post, but out of curiosity if you have any on hand, could you provide the PFI for one of those too?

----------

Anyway: sceUmdExecGetConfigurationCmd() - Sends the expected command 0x46
This function doesn't seem to exist in FW 6.60, at least not in umdman.prx, so this is just what FW 3.52 does.  (It's possible it maybe still lives on a different module, so it's worth trying regardless.)

Function that calls it creates a 0x36 byte buffer on the stack.  The first 0x20 are meant for a different function call I'm pretty sure, but just for the sake of authenticity, I'm writing exactly how the function sets it up before calling.

• 0x00-0x10 - int32 x 4
• 0x20-0x28 - unk8 x 8 (it calls memset() with a pointer to 0x20 and writes the value 0xFF eight times)
• 0x30-0x32 - int16 x 1 (store 0x08)
• 0x32-0x34 - int16 x 1
• 0x34-0x36 - int8   x 2

(Visualized)

sceUmdExecGetConfigurationCmd() is called with 3 arguments:

• $a0 - UMD drive returned by sceUmdManGetUmdDrive()
• $a1 - Pointer to 0x30 of that buffer
• $a2 - Pointer to 0x20 of that buffer

----------

Lastly: sceUmdExecReadDiscInfoCmd() - Sends the expected command 0x51
While this function does exist in FW 6.60's umdman.prx, there doesn't seem to be any function that calls it - so this is also just based off what FW 3.52 does and prepares before calling.

As with the function above, I'm pretty sure you can just create a 12 byte array, all memset()'d to 0xFF and use that alone, but for the sake of authenticity - it creates a 0x2C byte buffer on the stack:

• 0x00-0x10 - int32 x 4
• 0x10-0x12 - int16 x 1
• 0x20-0x2C - unk8 x 12 (it calls memset() with a pointer to 0x20 and writes the value 0xFF 12 times

(Visualized)

sceUmdExecReadDiscInfoCmd() is called with 3 arguments:

• $a0 - UMD drive returned by sceUmdManGetUmdDrive()
• $a1 - Number 12 (Likely the size of the buffer in the next arg)
• $a2 - Pointer to 0x20 of that buffer

----------

Random side note: The C library functions (at least the two that I've encountered - strncmp(), and memset()) seem to be unnamed in your asm dump.  Instead they're generic SysclibForKernel_NID() names, but luckily JPCSP has a more complete list of resolved NID hashes which was useful in cases like these.

[sarami]

I know you've already confirmed the multi-partition UMD GAME+MOVIE discs are most likely correct size in your original post, but out of curiosity if you have any on hand, could you provide the PFI for one of those too?

Stealth feat. WipEout Pure Stealth Edition https://redump.info/disc/57052/

Code: Select all

 00 00 00 00 00 00 00 00 12 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 16 00 00 80 00 31 E0 00 03 00 00 00 FC D3 3F
 00 09 C0 BF 00 03

Anyway: sceUmdExecGetConfigurationCmd() - Sends the expected command 0x46

Lastly: sceUmdExecReadDiscInfoCmd() - Sends the expected command 0x51

Thanks research. I'll code and test in the near future.

Random side note:

Thanks to you I know SysclibForKernel_NID().

[sarami]

sceUmdExecGetConfigurationCmd()
I coded, but the fuction error occurred (0x8021100f).

Code: Select all

    unsigned char bufConfig[0x36] = {};
    memset(&bufConfig[0x20], 0xff, 8);
    bufConfig[0x30] = 8;

    _sceUmdManWaitSema();
    res = _sceUmdExecGetConfigurationCmd(pUmdDrive, &bufConfig[0x30], &bufConfig[0x20]);
    _sceUmdManSignalSema();
    if (res < 0) {
        OutputPspError("_sceUmdExecGetConfigurationCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecGetConfigurationCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufConfig, sizeof(bufConfig));
        sceIoClose(uid);
    }

sceUmdExecReadDiscInfoCmd()
Also 0x8021100f error occurred.

Code: Select all

    unsigned char bufDiscInfo[0x2c] = {};
    memset(&bufDiscInfo[0x20], 0xff, 12);

    _sceUmdManWaitSema();
    res = _sceUmdExecReadDiscInfoCmd(pUmdDrive, 12, &bufDiscInfo[0x20]);
    _sceUmdManSignalSema();
    if (res < 0) {
        OutputPspError("_sceUmdExecReadDiscInfoCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecReadDiscInfoCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufDiscInfo, sizeof(bufDiscInfo));
        sceIoClose(uid);
    }

[Edness]

Error code 0x8021100F seems to be returned in some places by ata.prx.  More specifically, it seems to occur if the value at the address 0xBD700007 isn't divisible by 2 (or at least if bit 0 is set) after calling sceAtaAccessDataPort()?  Not sure.
Looking at the PSP memory map, it does seem to be in the ATA/UMDMAN hardware register region, at least.


Edit 1: This seems to have more info about those hardware registers.


Edit 2: Looks like those functions might be meant for the DVD drive present on devkits?  ata.prx has two functions - sceAtaIsDvdDrive() and sceAtaIsUmdDrive() - both of which seem to read from the same location.  The functions just read from 0x00000000, but I assume the system redirects these accordingly upon loading.  (Or maybe it's intentionally disabled like this?)

IsDvdDrive returns whatever value is currently there, but IsUmdDrive returns 0 or 1 if the (unsigned) value there is less than 1 (in other words a bool on whether the value is 0 or not.)  And both functions that later call sceUmdExecGetConfigurationCmd() and  sceUmdExecReadDiscInfoCmd(), first also call sceAtaIsUmdDrive() and exit out of it, if it doesn't return 0.

[sarami]

Random side note: The C library functions (at least the two that I've encountered - strncmp(), and memset()) seem to be unnamed in your asm dump.  Instead they're generic SysclibForKernel_NID() names, but luckily JPCSP has a more complete list of resolved NID hashes which was useful in cases like these.

Added the fuction name in documents.
https://github.com/saramibreak/UmdImage … asm352.txt
https://github.com/saramibreak/UmdImage … m352_c.txt