Search options (Page 2 of 2)

Here's mine from a TSSTcorp SE-208DB.  Looks like 3C 02 00 returned 0x8BC bytes of scrambled sector data.  So did F1 84, which was offset by about 13.5 sectors (0x7800 bytes).  And F1 8A returned the PFI, funnily enough.
Disc used: [PC] FlatOut 2 (Europe) (En,Fr,De,Es,It) (Xplosiv)

Are PS2 discs also disallowed or not?  At first I started with a PS2 disc since I have way more of those on hand, but shortly after restarted with a PC disc.  I don't know if you look for specific patterns in testing, but my assumption was that maybe you expect the 0th sector to be empty, which is not the case on PS2 discs since those have the PlayStation 2 logo seen when booting a game XORed across the first 12 sectors.

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.

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

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

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.

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

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

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