1 Reply by Edness

(29 replies, posted in General discussion)

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.

Go to forum: General discussion

2 Reply by Edness

(4 replies, posted in General discussion)

Yes, older systems are public.  Those three mentioned before, and newer systems (Wii U, PS4, PS5 etc.) are hidden from the public for now.  The PS3 Netflix disc seems to actually just be a BD-Video disc using BD-Live functionality to connect to the internet.

Go to forum: General discussion

3 Reply by Edness

(4 replies, posted in General discussion)

[BD-VIDEO] Netflix Instant Streaming Disc for PlayStation 3 (USA)

You need to be a dumper to view Audio CD, DVD Video, and BD Video sections.

Go to forum: General discussion

4 Reply by Edness

(29 replies, posted in General discussion)

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.

Go to forum: General discussion

5 Reply by Edness

(29 replies, posted in General discussion)

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

Go to forum: General discussion

6 Reply by Edness

(29 replies, posted in General discussion)

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.

Go to forum: General discussion

7 Reply by Edness

(29 replies, posted in General discussion)

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.

Go to forum: General discussion

8 Reply by Edness

(29 replies, posted in General discussion)

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.

Go to forum: General discussion

9 Reply by Edness

(29 replies, posted in General discussion)

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

Go to forum: General discussion

10 Topic by Edness

(0 replies, posted in Verifications)

[PS2] Sims, The - Bustin' Out (Korea)

Common Disc Info:
    Title: The Sims: Bustin' Out
    Foreign Title (Non-latin): 심즈: 세상 밖으로
    System: Sony PlayStation 2
    Media Type: DVD-ROM-5
    Category: Games
    Region: Korea (Republic of Korea)
    Languages: Korean
    Disc Serial: SLKA 25137

    Ringcode Information:
        Data Side Mastering Code (laser branded/etched): SLKA-25137    1
        Data Side Mould SID Code: 45V3
    Barcode: 0 14633 14723 0
    EXE/Build Date: 2003-11-16
    Comments:

[T:ISN] SLKA-25137
[T:DNAS] XX XX 00 20 8C
[T:EAID] 7182451 (Hologram)

Version and Editions:
    Version: 1.00
    Edition/Release: Original

Extras:
    Primary Volume Descriptor (PVD):

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 32 30 30                200
0330 : 33 31 31 31 36 31 34 34  37 32 31 30 30 24 30 30   3111614472100$00
0340 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 00 30   00000000000000.0
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 00   000000000000000.
0360 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0370 : 00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Size & Checksum:
    Size: 2138472448
    CRC32: a23c30b5
    MD5: 238ee8f20b0369b5bf58df02d52bd6c8
    SHA1: 259548b7bd18d729360aeca3ab5cdedb07ff3395

Dumping Info:
    Dumping Program: DiscImageCreator 20220909
    Manufacturer: TSSTcorp
    Model: CDDVDW SE-208DB
    Firmware: TS01
    Reported Disc Type: DVD-ROM

Go to forum: Verifications

11 Reply by Edness

(4 replies, posted in Verifications)

Yep.  My personal assumption was that they purposefully inverted the label scheme for promos later on just to reduce the confusion.  It was probably very easy for someone at Sony to quickly load the generic blue label preset, add the game title and studio logos etc., and not read if the text at the top says Demo or Promo, and just send it off to the pressing plant.

Go to forum: Verifications

12 Reply by Edness

(4 replies, posted in Verifications)

Not true.  While yes, early PS2 promo discs used the inverted label style that demos normally do, they would still say "Promo Only - Not For Resale" at the top.

Even the super early PS2 promos that use the PS1 promo label style say "Promo Only - Not For Resale."

The disc I've dumped says "Demo Only - Not For Resale" - this has to be a misprint.
https://cdn.discordapp.com/attachments/340499300754915329/1135540737090535505/Bez_nosaukuma.jpg

Go to forum: Verifications

13 Topic by Edness

(4 replies, posted in Verifications)

[PS2] Wacky Races Starring Dastardly & Muttley (Europe) (En,Fr,De,Es,It,Nl)
https://cdn.discordapp.com/attachments/ … 83_logs.7z

Common Disc Info:
    Title: Wacky Races Starring Dastardly & Muttley
    System: Sony PlayStation 2
    Media Type: CD-ROM
    Category: Games
    Region: Europe
    Languages: Dutch, English, French, German, Italian, Spanish
    Disc Serial: SLES-50183

    Ringcode Information:
        Data Side Mastering Code (laser branded/etched): Sony DADC   A0100369365-0101   18
        Data Side Mastering SID Code: IFPI L558
        Data Side Toolstamp or Mastering Code (engraved/stamped): A1
        Data Side Mould SID Code: IFPI 943N
    Error Count: 0
    EXE/Build Date: 2001-05-22
    Comments:

[T:ISN] SLES-50183
<b>Disc ID</b>: 0019306 (Demo)
[T:VOL] SLES_50183
[T:DNAS] 00 00 00 00 04
Demo edition is a misprinted Promo edition

Version and Editions:
    Version: 1.02
    Edition/Release: Demo

Extras:
    Primary Volume Descriptor (PVD):

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 32 30 30                200
0330 : 31 30 35 32 33 31 31 30  34 34 33 30 30 24 30 30   1052311044300$00
0340 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 00 30   00000000000000.0
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 00   000000000000000.
0360 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0370 : 00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Tracks and Write Offsets:
    DAT:

<rom name="SLES_50183.bin" size="711188352" crc="7ccd09a4" md5="7a0a82e1b28128a06362e3295d4c4cad" sha1="afbe182fa3cd7eb9180836aa72ac05689e4ec44f" />

    Cuesheet:

FILE "SLES_50183.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00

    Write Offset: -647

Dumping Info:
    Dumping Program: DiscImageCreator 20220909
    Manufacturer: PLEXTOR
    Model: DVDR    PX-716A
    Firmware: 1.11
    Reported Disc Type: CD-ROM XA Disc

Go to forum: Verifications

14 Reply by Edness

(3 replies, posted in General discussion)

Yep, it seems the site has been configured to only create the Metadata field for PS3 entires if it's a Blu-Ray, so the key has been put there.  If iR0b0t ever returns, that might be fixed, but I'm not keeping my hopes up :P

The PS3 MIA wiki page keeps track of Disc Keys as well, and it was only these few DVD dumps that had to be added in comments, which wouldn't be added to the downloaded key set.
http://wiki.redump.org/index.php?title= … n_Comments

Go to forum: General discussion

15 Reply by Edness

(3 replies, posted in General discussion)

It's a common key applicable to all PS3 debug discs.

http://forum.redump.org/topic/47712/fix … disc-keys/

https://www.psdevwiki.com/ps3/Keys#sv_i … 001_-_3.55

Go to forum: General discussion

16 Reply by Edness

(2 replies, posted in General discussion)

I started adding EXE dates to Xbox/360 submission comments some time ago, and Enker didn't seem to mind those, back when he was a mod.  Although I should note XBEExplorer and XEXTool both do dumb things by adjusting the timestamp to your local timezone, so you'll get a different timestamp depending on where you are.

Which is why a friend and I wrote a script to get the timestamp from various Microsoft formats that are consistent for everyone.

Go to forum: General discussion

17 Reply by Edness

(43 replies, posted in General discussion)

Here's all of mine so far.  A few are XGD3 and therefore no security sector binaries for them, but the rest are fine.  Some also have multiple binaries, because I dumped from multiple discs that were the same, but with a different hash for DMI and/or SS.  (Except for Assassin's Creed III, which is multi-disc.)

Go to forum: General discussion

18 Topic by Edness

(1 replies, posted in Guests & account requests)

Hi again, I'd like to request a wiki account to add a few titles not mentioned on the undumped disc lists.

Go to forum: Guests & account requests