redump.info Forum

Results:

https://cdn.discordapp.com/attachments/ … 062411.jpg

Also, the game itself has English, Spanish, and French language support.

ajshell1 wrote:Results:

https://cdn.discordapp.com/attachments/ … 062411.jpg

Also, the game itself has English, Spanish, and French language support.

Thank you!

Bumping, These Orange entries should be turned Green.

added: Output PARAM.SFO into _disc.txt
https://github.com/saramibreak/UmdImageCreator/releases

Do all psp UMDs have default layerbreak? Is there a sort of file like .dvd that stores layerbreak info? I'm working on my psp collection and reorganising to match redump checksums and being possibly closest to perfect dump, so i need to know how umd layerbreak works. In ps2 DVD9s layerbreak is not constant. Is there a tool that can verify if all psp dumps have the same layerbreak (or maybe if you know this i don't need such tool)?

I recently analyzing some prx files. The result is here. https://github.com/saramibreak/UmdImage … master/Doc

If someone can read MIPS code, please tell me the usage of the SCSI-like function (e.g. sceUmdExecReadUMDStructureCmd, sceUmdExecRead10Cmd, etc).

According to the function name, sceUmdExecReadUMDStructureCmd looks like ReadDVDStructure of the SCSI-command, which can read PFI and DMI etc.

sarami wrote:If someone can read MIPS code, please tell me the usage of the SCSI-like function (e.g. sceUmdExecReadUMDStructureCmd, sceUmdExecRead10Cmd, etc).

According to the function name, sceUmdExecReadUMDStructureCmd looks like ReadDVDStructure of the SCSI-command, which can read PFI and DMI etc.

Depends on what exactly you need, but I stumbled upon this post while looking for other stuff.  I glanced over those functions from FW 6.60 umdman.prx that I had layinig around (the functions seemed mostly identical to the asm dump you've provided presumably from FW 3.52, just with different addresses) and mapped the names accordingly as well.

In your asm dump, the ReadUMDStructure function is called from two places, but in mine it seems to only be done once (unless I messed up somewhere) which matches the one at 0x0000E024 in yours, but I digress.  It clears a 0x48 byte buffer on the stack first; assuming the sw/sh/sb instructions used to clear it are indicative of the size of each component:

• 0x00-0x08 - int32 x 2
• 0x08-0x0A - int16 x 1 (store 0x28)
• 0x0A-0x10 - int8   x 6
• 0x20-0x48 - int32 x 10

(Visualized - 0x00 = unused(?), 0x11 = int8, 0x44444444 = int32)

Finally, sceUmdExecReadUMDStructureCmd() takes three arguments:

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

The other place where it's called in your asm dump is in 0x0000C340, which differs by writing the number 32 as an int16 at 0x08 in the 1st array, and only clearing 2 x int32s in the 2nd array.  It also seems to be stored the other way around, so the 2nd argument is a pointer to 0x20, and the 3rd is a pointer to 0x00, but that's likely meaningless, though it does mean the buffer is 0x30 bytes in size instead of 0x28.  (Visualized)

The function itself, among other things, calls a function with the args 0xAD and the UMD drive, which lines up with the SCSI command READ_DVD_STRUCTURE (0xAD).  It also reads the int16 value at 0x08, subtracts it by 4, and writes it back in that location after it.  So if, say, the 0xAD command succeeded but something else failed, this could probably be a way of checking if it at least got that far into the ReadUMDStructure function.

If the function encounters a problem, it'll return the error code 0x80010016 (named PSP_ERROR_UMD_INVALID_PARAM in PPSSPP).

@Edness
Thanks the detailed information.

Letting you know I've just made a slight amendment to my original post.  I completely overlooked that it also writes the number 40 at 0x08 in the 1st function, which I originally marked as unused.

Edness wrote:it also writes the number 40 at 0x08 in the 1st function

As you say, I set 40 at 0x08.
As a result, non-zero bytes are written in _sceUmdExecReadUMDStructureCmd.bin
Disc is Mugen Kairou https://redump.info/disc/53372/
It seems 0x28 at 0x21 is the size from 0x20 to 0x47. Other non-zero bytes are unknown now.

EDIT1:
Disc is Dissidia 012: Duodecim Final Fantasy https://redump.info/disc/25036/
EDIT2:
Disc is Jigen Kairou https://redump.info/disc/54489/