UmdImageCreator (Page 1 of 3)

It's not working on my hacked PSP3000 with 660 PRO-C.

Pressing the Note button does nothing, and the eboot version cannot be started because the data is corrupt.

Does your tool dump these properly? http://redump.org/discs/system/psp/status/3/

also, does your tool dump the same way as PSP Filer, or is there a chance that dumps with your tool are more complete?

sorry if any of these questions are stupid or already answered

Perhaps yes. I think these dumps are good because there isn't a gap between GAME and VIDEO.

I tested some discs by PSP Filer and my tool, and comfirmed same hash is outputted.

But problem is  UMD VIDEO disc, not GAME VIDEO hybrid disc.
----
ACUM-34031 (Final Fantasy VII - Advent Children)
Log on GAME

pspUmdTypes: 0x60 (VIDEO AUDIO)

L0 length: 21504 (0x05400)
0x01F20014 is unknown: 05 80 00 32
0x01F200A0 is unknown: 01

Log on XMB

pspUmdTypes: 0x60 (VIDEO AUDIO)

L0 length: 421056 (0x66cc0)
L1 length: 264112 (0x407b0)
-----------------
    Total: 685168 (0xa7470)

0x01F20014 is unknown: 05 80 00 32
0x01F200A0 is unknown: 01

21504  + 421056 = 442560 (layerbreak)
But as you know, UMD VIDEO can't dump on GAME. So, 21504 sectors are undumpable.

Hi, ajshell1, can you please dump this hybrid disc with UMDKiller mod?
http://forum.redump.org/post/62111/#p62111
and compare the dump

Results:

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

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

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)?

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).

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.

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

Info derived from your hexdumps:

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

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

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.

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.