Filesystem

The PSP counts many storage partitions, some of which are external drives, whilst the other are partitions on the NAND flash.

Read and Write access

The filesystem contains many media which can be accessed for read. Some media should never be wrote to, as it could damage the system and so are read-only by default, in usermode. With kernel access, it is possible to write to raw partitions and to mount some partitions in write mode.

Mountpoints

• ms0 - Memory Stick
• lflash - Flash Memory (?entire and raw?)
• ipl - Part of Flash Memory - Initial Program Loader
• idstorage - Part of Flash Memory - IDStorage leaves specific to the PSP hardware
• flash0 - Part of Flash Memory - firmware files
• flash1 - Part of Flash Memory - XMB settings, network configurations and the background image in 2.00 and above
• flash2 - Part of Flash Memory - In firmwares 3.00 and up, this contains the half of the DRM for Sony's official PS1 emulator (the other half being in the flash0)
• flash3 - Part of Flash Memory - Unused and about 1 MiB in size although in custom firmwares it can be used along with flash2 to redirect firmware elements such as fonts.
• flash4 - Part of Flash Memory - Upon examination of the 3.71 firmware, it was discovered that there were references to a flash4 and flash5. However, they cannot be mounted. It is suspected that they are unformatted and may be for future use hence why they cannot be read.
• flash5 - Part of Flash Memory - Reserved and unused just like flash4
• disc0 - UMD Drive as LBA sectors
• umd0 - UMD Drive as iso9660 partition
• irda0 - Infrared Port (only present in PSP 1000)

umd0

umd0 is a mounting point for the UMD as an ISO9660 filesystem (also known as ECMA-119).

By Path

Example of paths:

• "umd0:/PSP_GAME/PARAM.SFO"
• "umd0:/PSP_GAME/SYSTEM/PARAM.SFO"

disc0

disc0 is a mounting point for the UMD as raw sectors indexed by LBA and restricted to a given size. It cannot be considered as an alias to umd0 because umd0 comes with a filesystem, ?unlike disc0? and because disc0 supports ?or requires? arguments unlike umd0.

By LBA sectors

The PSP IoFileMgr API allows a usermode process to open a file contained on a UMD by specifying its LBA index and size like this:

sceIoOpen("disc0:/sce_lbn0x%04x_size0x%04x", flag, mode);

where e.g. name = "disc0:/sce_lbn0x5CEB0_size0x3CFFB1", flag = 00000001, mode = 000001b6.

The protocol sceIoOpen("disc0:/sce_lbn0x%04x_size0x%04x", ...) is used in a few PSP games like Naruto Shippuden Ultimate Ninja Impact, Final Fantasy 4, Blood and Nanoha games. The reason these games use disc0 API instead of umd0 API may be that they could not store some files violating iso9660 filesystem rules, or because they wanted to speedup read access by specifying directly LBA index instead of a string path.

See reimplementation source code in uofw.

By Path

This section has to be verified: does disc0 support paths, and is it an alias for umd0?

Example of paths:

• "disc0:/PSP_GAME/PARAM.SFO"
• "disc0:/PSP_GAME/SYSTEM/PARAM.SFO"

"In April 2005, a DNS redirection trick was discovered in the game Wipeout Pure's content-downloading feature that allowed regular HTML web pages to be displayed in its place. Using this trick, and with a bit of guess work, hackers spotted that navigating to addresses such as file:///disc0:/ would allow files from the UMD to be viewed"

ms0

This is a list of default folders created by the PSP System Software in a memory stick inside a PSP 1000 running firmware 6.60.

• MP_ROOT
  • 100MNV01
  • 101ANV01
• MUSIC
• PICTURE
• PSP
  • COMMON
  • GAME
  • RSSCH
  • SAVEDATA
  • SYSTEM
    • BROWSER
    • INFOBOARD
      • TEMP
        • IMAGE
  • THEME
• VIDEO

These folders are automatically created when formatting the Memory Stick using the PSP formatter. To trigger that format menu, one can insert a memory stick that is formatted with another filesystem than FAT32, or no filesystem at all. It is also possible to format the Memory Stick as FAT32 on an external device, in which case the default folders are not created by the PSP (to be fact-checked).

ms0 on PPSSPP emulator

Since PPSSPP 1.4, fixes have been made to make homebrew easier to test. Placing the folder containing the project inside of PPSSPP/Memstick/PSP/GAME will result in the correct argument passed to main() (ms0:/PSP/GAME/APPLICATION/EBOOT.PBP) instead of umd0:/. The latter path is to support ISO PBP and PS1 games. This means it is possible to emulate a UMD on PPSSPP, but in order to do it on a real PSP, CFW or a signed PBP must be present. Below is a list of default PPSSPP folders, which differs from the PSP initially.

• MUSIC
• VIDEO
• PICTURE
• PSP
  • COMMON
  • GAME
  • SAVEDATA
  • SYSTEM

Pathing Conventions

The PSP is more unix-like than when it comes to paths. The general path convention has forward slashes "/" to delimit protocols, directories, and files. Everything should be uppercase, likewise, any file or directory will be referenced despite it's capitalization - it is not case sensitive. This means "BIN" is "bIN" as well as "bIn". It would make sense to keep everything uniform and uppercase it following this rule, so it is best practice to make files and folders uppercase.

Absolute Paths

An absolute path includes a protocol which directly links, through all paths, to a file or directory. Absolute links are the most secure in that they point to a location no matter where the Current Working Directory (CWD) is. It is recommended to use an absolute path when necessary.

Example Paths

• umd0:/FOLDER/file.txt
• ms0:/PSP/GAME/APPLICATION/EBOOT.PBP
• ms0:/MUSIC/HomeBySafia.mp3

Relative Paths

A relative path takes the CWD and builds the path based on it. For example, if the current working directory is ms0:/PSP/GAME/APPLICATION, a relative path could reference GAME/OTHER_APPLICATION. To do this uses a series of double periods to denote previous directory, however, it is not necessary to use previous directories with this method as it builds off the CWD too. This means ms0:/PSP/GAME/APPLICATION could be the CWD and to reference a folder inside called FILES, all there needs to be is /FILES.

Example Paths Filesystem (ms0:/)

• MUSIC
• PSP
  • GAME
    • APPLICATION
      • FILES
    • OTHER_APPLICATION
      • FILES
      • DATA

Example Paths for CWD (ms0:/PSP/GAME/APPLICATION)

• /FILES
• ../OTHER_APPLICATION
• ../OTHER_APPLICATION/FILES
• ../OTHER_APPLICATION/DATA
• ../../../MUSIC

Path Concatenation

One common trick is to use the literal concatenation strategy, which has the counterpart to where you malloc or calloc some memory, and do the string concatenation there - using dynamic memory. The literal concatenation is not on the dynamic memory and on the automatic stack.

Malloc/Calloc avoiding literal concatenation

// make some zero terminated literals
#define abc "abc"
#define onetwothree "123"

// concat them by specifying variable
const char* abc_onetwothree = abc onetwothree;
printf(abc_onetwothree); //> abc123

Current Working Directory

The PSP has concept of the current working directory (CWD). This is always the boot location of the PBP file. While emulating a UMD, the CWD is the root folder inside the EBOOT.PBP, which is umd0:/. In order to set the CWD, PSPDEV provides the function sceIoChdir(). sceIoChdir() takes in a const char* that points to the new path to be the CWD. Once set, it is unknown to read back the CWD using the provided sceIo* functions. Such a function is found in unistd.h as getcwd() and in windows.h as _getcwd().

Throwing It All Together

Absolute paths are the way to go. Messing with CWD in PSP is a bit cumbersome. It is even more cumbersome when detecting the medium the EBOOT.PBP came from. As stated in Hello World Application, the parameter passed to main() will tell you the absolute path to the EBOOT.PBP. A better way than to substring this and build off of it is using Path Concatenation. This makes for absolute paths easy. The problem would be the folder's name is dependent on the user not editing the name.

Example

#define TITLE "APPLICATION"
#define ROOT "ms0:/PSP/GAME/" TITLE "/"

Doing this method also enables placing the TITLE macro inside of the PSP_MODULE_INFO() function. If emulating a UMD, the path would be umd0:/ instead of directly from memstick (ms0:/).