The PSP has 11 partitions, three of which are external drives, the other being partitions on the NAND:
- ms0 - Memory Stick
- flash0 - Flash Memory (Contains all the firmware files)
- flash1 - Flash Memory (Used to store the XMB settings, network configurations and the background image in 2.00 and above)
- flash2 - 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 - Flash Memory Currently 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 - 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 - same as flash4
- disc0 - UMD Drive
- ipl - Initial Program Loader
- irda0 - Infrared Port (Not present in PSP 2000)
- idstorage - Contains the IDStorage keys specific to the PSP hardware. Damage to the keys can result in homebrew and UMDs no longer running.
The filesystem contains many media which can be accessed. Some media should never be wrote to, as it could brick the system like the risk using kernel mode has. With kernel mode, the media restricted here will not be talked about, but told what should be restricted.
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.
A protocol determines the medium in which is being referenced. There are quite a few media in which there is ability to reference. Below are a list of the common ones that are safe to use.
- umd0:/ - a UMD disc
- ms0:/ - the memory stick
- disc0:/ - a UMD disc
Stay away from
The Memorystick Root
The root of the memory stick is the base of all the folders. In windows, this is commonly your C:/ drive. However, with the PSP it is the memorystick. The memorystick may list as any protocol when plugged into your computer. Depending on your PNP settings, it may not mount and will have to be mounted manually.
This is a list of default folders in your memory stick with firmware 6.60 PSP 1000 CFW.
The root would be the first level of folders. Inside of those folders aren't the root anymore and colloqiually change to 'the GAME folder root', pertaining to anything in the PSP/GAME folder.
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.
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.
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:/)
Example Paths for CWD (ms0:/PSP/GAME/APPLICATION)
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
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.
#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:/).
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().