26
FILE FORMATS
135
26.2.3
Unique ELF type
PRX files report the value 0xFFA0 as their type in the header instead of 0x0002 which is usual for normal MIPS ELF files.
26.3
PBP
A PBP file collects the files needed for a game executable from a MemoryStick into a single file, for easier transfer. The files are simply
concatenated with a small index at the start. There does not seem to be any alignment requirements.
All the offsets are in bytes from the beginning of the PBP file, and store in unsigned little endian 32 bit format (ul32).
start
end
size
description
0
3
4
0 "PBP" A file type identification cookie. A zero byte is followed by the three uppercase ASCII characters
"PBP"
4
7
4
0 0 1 0 This might be some kind of indication of the PBP version. Currently it’s always two 0 bytes followed
by a 1 byte and then one more 0 byte.
8
11
4
ul32 Offset of param.sfo data
12
15
4
ul32 Offset of icon0.png data
16
19
4
ul32 Offset of icon1.pmf data
20
23
4
ul32 Offset of PNG image of unknown purpose
24
27
4
ul32 Offset of pic1.png data
28
31
4
ul32 Offset of snd0.at3 data
32
35
4
ul32 Offset of PSP data
36
39
4
ul32 Offset of PSAR data
26.4
PSF (SFO)
PSF files are used in various places on the PSP to store metadata about other files. It contains a list of keys, and the values associated
with these keys. This can be information such as parental level, and language. Numerical data is stored in little endian format, I will use
the notation ul32 for "unsigned little endian 32 bit" etc.
The file starts with a header, giving the number of key/value pairs and the offsets for the main parts of the file:
start
end
size
description
0
3
4
0 "PSF" A file type identification cookie. A zero byte is followed by the three uppercase ASCII characters
"PSF".
4
7
4
1 1 0 0 This might be some kind of indication of the PSF version. Currently it’s always two 1 bytes followed
by two 0 bytes.
8
11
4
ul32 Offset from the start of the file to the start of the key table (in bytes)
12
15
4
ul32 Offset from the start of the file to the start of the value table (in bytes)
16
19
4
ul32 Number of key/value pairs in the index
This header is immediately followed by the index table, which has one entry per key/value pair. This table seems to always be sorted
alphabetically on the key string, allowing binary search to be used, although it is unknown if this is actually guaranteed. The entries
look like this:
start
end
size
description
0
1
2
ul16 Offset of the key name into the key table (in bytes)
2
2
1
4 Unknown, always 4. Maybe alignment requirement for the data?
3
3
1
ul8 Datatype of the value, see below.
4
7
4
ul32 Size of value data, in bytes
8
11
4
ul32 Size of value data plus padding, in bytes
12
15
4
ul32 Offset of the data value into the value table (in bytes)
Value data is always aligned to a 4 byte boundary, so if the size of the data is not dividable by four, the data is padded with zero
bytes. The two size fields in the index entry gives the size with and without this padding, respectively. It is allowed to add arbitrary
amounts of extra padding (as long as alignment is ensured), which makes it easier to modify data in place. Some games seem to take
advantage of this to update the text descriptions as the player progresses in the game.
After the index table comes the key table, at the offset (from the beginning of the file) indicated in the file header. Each key is a NUL-
terminated ASCII string. The keys are referenced from the index table by offset from tge key table start, so the first key will have offset
0.
Summary of Contents for PlayStationPortable
Page 114: ...12 AUDIO PROCESSING 114 12 Audio Processing 12 1 Overview 44100 Hz Sample Frequency ...
Page 116: ...14 WLAN 116 14 WLAN ...
Page 117: ...15 USB PORT 117 15 USB Port ...
Page 118: ...16 UMD 118 16 UMD ...
Page 119: ...17 MEMORY STICK 119 17 Memory Stick ...
Page 128: ...21 FLASH MEMORY STRUCTURE FLASH1 128 21 Flash Memory Structure flash1 DIC REGISTRY VSH THEME ...
Page 141: ...28 IPL 141 28 IPL ...
