I created umd disc dumping tool to verify some question.
https://github.com/saramibreak/UmdImageCreator

Related topic: http://forum.redump.org/topic/209/psp-dumping/


http://forum.redump.org/post/61914/#p61914

Jackal wrote:

the PSP is accessing the data through the filesystem.. So the last sectors of a PSP dump could be erroneous and some tools are known to create bad dumps.

No problem if it uses ioctl (sceIoIoctl/sceIoDevctl).

http://forum.redump.org/post/60816/#p60816

Enker wrote:

We probably won't be able to add these dumps to Redump until there's a dumping tool that can dump both partitions at once, to ensure that there isn't a gap between them.

I tested ULJM-05105 (Stealth feat. Wipeout pure Stealth edition).
Log on GAME

pspUmdTypes: 0x30 (GAME VIDEO)

L0 length:  62256 (0x0f330)
0x01F20014 is unknown: 05 80 00 32
0x01F200A0 is unknown: 20

Log on XMB

pspUmdTypes: 0x30 (GAME VIDEO)

L0 length: 380304 (0x5cd90)
L1 length: 431104 (0x69400)
-----------------
    Total: 811408 (0xc6190)

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

62256 + 380304 = 442560 (it matched layerbreak). So, there isn't a gap between GAME and VIDEO.

2 (edited by tossEAC 2018-07-16 17:41:34)

Does the resulting iso work as it should.

If put in ISO folder, does it work as a game.
And if you put it in ISO\Video does it work as a Video.

If so I would say you are on the right track.

He who controls the SPICE... controls the UNIVERSE!
The SPICE must flow.

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.

tossEAC wrote:

If put in ISO folder, does it work as a game.
And if you put it in ISO\Video does it work as a Video.

changed: output directory

ajshell1 wrote:

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

changed: PSP_FW_VERSION 150 -> 661 (but I don't know this is correct or not.)

5 (edited by Jackal 2018-07-16 21:17:17)

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

Don't miss the LedZep's tool, he has even posted it a little earlier than sarami - http://forum.redump.org/post/62111/#p62111

Jackal wrote:

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

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

Jackal wrote:

also, does your tool dump the same way as PSP Filer

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.

8 (edited by ajshell1 2018-07-17 18:45:31)

I just finished dumping my (formerly user7/dizzzy's) copy of Stealth + Wipeout Pure.

Here are the output hashes:

ULUS-10058.iso  5ef803ca  386bfb26919a8f95d7300227b5b3d215  ea642afa63a3c36b7f55c407484ef4dc030cd5f2

Now what?

Also, sarami, you need to make this thing dump faster. It's too slow currently. It took several hours for my copy to dump.

(I'm attaching all output files except the 0B _mainError.txt file (because I don't want to upload an empty file tongue).

Post's attachments

ULUS-10058_disc.txt 197 b, 25 downloads since 2018-07-17 

ULUS-10058_mainInfo.txt 123.88 kb, 21 downloads since 2018-07-17 

ULUS-10058_volDesc.txt 51.77 kb, 22 downloads since 2018-07-17 

You don't have the permssions to download the attachments of this post.

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

I'll test it out. I'll try to give you the results tomorrow.

11 (edited by ajshell1 2018-07-19 11:18:23)

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!

13 (edited by user7 2018-07-28 16:04:31)

Bumping, These Orange entries should be turned Green.

All my posts and submission data are released into Public Domain / CC0.

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.

17 (edited by Edness 2023-09-23 14:16:45)

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.

20 (edited by sarami 2023-09-22 04:30:10)

Edness wrote:

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

As you say, I set 40 at 0x08.

    unsigned char bufStruct[72] = {};
    bufStruct[8] = 40;
    _sceUmdManWaitSema();
    res = _sceUmdExecReadUMDStructureCmd(pUmdDrive, bufStruct, &bufStruct[32]);
    _sceUmdManSignalSema();
    if (res < 0) {
        OutputPspError("_sceUmdExecReadUMDStructureCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecReadUMDStructureCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufStruct, sizeof(bufStruct));
        sceIoClose(uid);
    }

As a result, non-zero bytes are written in _sceUmdExecReadUMDStructureCmd.bin
Disc is Mugen Kairou http://redump.org/disc/53372/

 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 28 00 00 80 00 01 E0 00 03 00 00 00 04 5D 5F
 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

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 http://redump.org/disc/25036/

 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 28 00 00 80 00 31 E0 00 03 00 00 00 FC AB 2F
 00 09 C0 BF 00 01 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

EDIT2:
Disc is Jigen Kairou http://redump.org/disc/54489/

 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 28 00 00 80 00 01 E0 00 03 00 00 00 05 07 BF
 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

21 (edited by Edness 2023-09-22 06:14:29)

Nice, looks like raw PFI data is written at 0x24.
https://media.discordapp.net/attachments/340499300754915329/1154641604242571284/Screenshot_20230922-075246_Samsung_Internet.png

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.

22 (edited by sarami 2023-09-22 07:49:24)

Changed to 16.

bufStruct[8] = 16;

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

 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.

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.

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.

25 (edited by Edness 2023-09-22 14:41:54)

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