Threaded Mode | Linear Mode

ZiNgA BuRgA · 20/01/2007 06:58 AM

Note: This only explores the PSAR section of the EBOOT. The rest of the EBOOT is the same as standard EBOOTs so see the PBP File structure guide for more info. Also, this refers to the decrypted EBOOT format used in the 3.0x OE popstation, not offical Sony EBOOTs.

This only focuses on the PSAR section of the EBOOT for PSX EBOOTs. For 3.02 OE-B EBOOTs, the PSAR section had to go at 0x50000 (according to Dark_AleX - I've heard reports that the start can go elsewhere). Now the PSAR section isn't fixed, starting from 3.03 OE-A.

One thing to note, the PSAR is divided into two parts.

Contents

PSAR Section 1
PSAR Section 2
TOC (Table of Contents
ISO Indexes

First part contains the actual ISO:

Offset	Type/Size	Purpose
0x00	12 bytes	PSAR Signature - always is the string "PSISOIMG0000"
0x1B	DWord	Offset to the second part
0x400	11 bytes	Game ID in the format "_????_#####" (?=character, #=digit)
0x800		Start of TOC information (see TOC for more info)
0x122C	128 bytes	Game Save (if the text is too short, the remaining bytes are null)
0x4000		Start of ISO Indexes (see ISO Indexes for more info)
0x10000		Beginning of ISO - note the ISO may be padded with null characters

The second part of the PSAR immediately follows the ISO:

Offset	Type/Size	Purpose
0x00	8 bytes	The string "STARTDAT"
0x10	DWord	Size of the "STARTDAT" header in bytes (always seems to be 0x50)
0x14	DWord	The size of the gameboot PNG, in bytes

This header section is padded with nulls to satisfy the "STARTDAT header" value.  Following this section, is the gameboot PNG file.  Following the PNG is a "PGD" - possibly something to do with the Documentation???

TOC (Table of Contents)
The PSP's pops emulator uses the standard TOC format.  The TOC describes track information - some games use CD-DA audio, meaning that there's one data track, and multiple audio tracks on the disc.
Here's a breakdown - each "record" or "entry" consists of 10 bytes.  Here's an example:

Code:

00020800h: 41 00 A0 00 00 00 00 01 20 00 01 00 A1 00 00 00 ; A. ..... ...¡...
00020810h: 00 15 00 00 01 00 A2 00 00 00 00 69 59 74 41 00 ; ......¢....iYtA.
00020820h: 01 00 00 00 00 00 02 00 01 00 02 02 42 48 00 02 ; ............BH..
00020830h: 44 48 01 00 03 02 51 18 00 02 53 18 01 00 04 04 ; DH....Q...S.....
00020840h: 06 67 00 04 08 67 01 00 05 05 19 03 00 05 21 03 ; .g...g........!.
00020850h: 01 00 06 08 31 41 00 08 33 41 01 00 07 11 50 10 ; ....1A..3A....P.
00020860h: 00 11 52 10 01 00 08 15 01 54 00 15 03 54 01 00 ; ..R......T...T..
00020870h: 09 18 19 42 00 18 21 42 01 00 10 21 33 41 00 21 ; ...B..!B...!3A.!
00020880h: 35 41 01 00 11 21 43 10 00 21 45 10 01 00 12 24 ; 5A...!C..!E....$
00020890h: 07 34 00 24 09 34 01 00 13 25 04 25 00 25 06 25 ; .4.$.4...%.%.%.%
000208a0h: 01 00 14 26 18 25 00 26 20 25 01 00 15 29 42 38 ; ...&.%.& %...)B8
000208b0h: 00 29 44 38 00 00 00 00 00 00 00 00 00 00 00 00 ; .)D8............

Sorting it out into 10 byte chunks:

Code:

41  00  A0  00 00 00  00  01 20 00   <-- describes the first track
01  00  A1  00 00 00  00  15 00 00   <-- describes the last track
01  00  A2  00 00 00  00  69 59 74   <-- describes the lead-out

41  00  01  00 00 00  00  00 02 00
01  00  02  02 42 48  00  02 44 48
   [...]
01  00  15  29 42 38  00  29 44 38

Note, TOC uses "binary decimal" for various things - that is 0x60 = 60 in "binary decimal".
Okay, here's the breakdown:

Offset	Type/Size	Purpose
0x00	1 byte	Track type - 0x41=data track, 0x01=audio track
0x01	1 byte	Always null
0x02	1 byte	The track number in "binary decimal"
0x03	3 bytes	The absolute track start address in "binary decimal" - first byte is minutes, second is seconds, third is frames
0x06	1 byte	Always null
0x07	3 bytes	The "relative" track address - same as before, and uses MM:SS:FF format

Note that there's three special tracks at the beginning - these have track "numbers" A0, A1 and A2 (also note that a TOC cannot have more than 99 tracks).
The structure of these are slightly different - the absolute track field is always null:
Track "A0" - 41(type of track 1?) 00 A0 00 00 00 00 First track number 20(disc type, 20=XA) 00

Code:

41  00  A0  00 00 00  00  01 20 00

Track "A1" - 01(type of last track?) 00 A1 00 00 00 00 Last track number 00 00

Code:

01  00  A1  00 00 00  00  15 00 00

Track "A2" - 01 00 A2 00 00 00 00 Length of disc in the same format as normal track entries, MM:SS:FF

Code:

01  00  A2  00 00 00  00  69 59 74

ISO Indexes
Each index is 32 bytes long:

Offset	Type/Size	Purpose
0x00	DWord	Offset of block
0x04	DWord	Size of block (see note below)

the other 24 bytes are just junk
Blocks - uncompressed blocks are 16*2352 bytes (there's 2352 bytes per CD sector). Although ISO sectors only have 2048 bytes per sector (don't include RAW data) the uncompressed block size is always 16*2352 bytes long.
Compressed blocks are compressed with zlib.

Anyways, I'm still looking into this format - mainly for my popstation GUI :)

michaelp · 06/02/2007 03:54 PM

cool
any way to open .psar files

ZiNgA BuRgA · 08/02/2007 01:50 AM

michaelp Wrote:any way to open .psar files

Dunno what you're on about.

This is the format of the decrypted PSX PSAR section... A normal PSAR is quite different.

11/04/2009 11:27 AM

Sparker · 11/04/2009 11:27 AM

Good info

30/11/2009 07:45 AM

Sparker · 30/11/2009 07:45 AM

http://endlessparadigm.com/forum/showthr...#pid266401

Threaded Mode \| Linear Mode [Random Info] (decrypted) PSX EBOOT (PSAR) Format
Author	Message