emulators.ppsspp.Ppsspp

RomM platform key, ppsspp.

Human-readable name shown in the UI.

On; activate empties both save subtrees.

The emulated memory stick root, which the save subtrees hang off.

SAVEDATA and PPSSPP_STATE, the directories the save archive carries.

True, states are saved and loaded over the bracket hotkeys.

The one slot the broker works in, echoed back as the effective slot.

Where PPSSPP writes .ppst files.

The PPSSPP log the broker exposes.

Bootable ROM formats, best first, then the archive formats while the cache is on.

Set up the process state and the launch sequence counter that fences deferred loads.

Resolve a RomM path to the ROM to boot.

A file is taken as is, an archive once its members show a PSP image. A directory is searched one level deep for the best candidate by _pick_rom_file, and when it holds none, a lone archive holding one is taken instead. A pattern that cannot be walked (an unreadable subdirectory, a broken mount) costs only what that pattern would have contributed: the candidates already found still rank, since reporting a title unbootable over one bad directory is worse than booting the best of what could be read.

Whether an archive can be booted: the cache is on and a member is a PSP image.

A ROM folder's lone archive, for a folder holding no PSP image of its own.

Only the shallowest archives count, so one in an extras subfolder never makes the game's own archive ambiguous. Several at that depth are refused rather than guessed between.

Run one xdotool command against the session display.

Find the window this launch is running the game in.

Two things have to hold. The window must belong to the process this broker spawned, since a window left behind by the previous emulator process carries the same class and title shape and would swallow the save hotkey, and its title must carry _GAME_TITLE_MARK, which PPSSPP only appends once a game is loaded: before that the window is a menu a hotkey does nothing useful to.

Poll until this launch has a game window up, or deadline passes.

Focus the game window and send key through XTEST.

Activating first is what makes this survive the player clicking back into the page: XTEST delivers to whatever holds focus, so a key sent at an unfocused PPSSPP goes to the desktop instead.

Stop any running instance, patch the inis, and start PPSSPPQt.

The binary comes from env PPSSPP_BIN (default PPSSPPQt). With resume_slot set, a deferred thread waits for the state file and loads it over the hotkey once the window is up.

An archive is extracted into the cache first (or its earlier extraction reused), and the PSP image inside it is what boots.

Raises

• RuntimeError: When either ini could not be patched or an archive could not be extracted, so nothing is spawned; see _patch_ini_file.

Wait for the resume state and a booted game, then load it over the hotkey.

Both waits share RESUME_LOAD_WAIT. The window wait is the load-bearing one: a resume state restored from the save archive is already on disk when the thread starts, so waiting only on the file would fire the one hotkey this path ever sends seconds into a boot with no window to take it, losing the resume silently. Once the game window is up, RESUME_LOAD_SETTLE covers the rest of PPSSPP's own boot. Abandons itself whenever seq no longer matches the current launch, so a superseded launch never gets a stray load.

Save a state into the broker's slot over the hotkey and wait for it to land.

slot is what RomM asked for and is ignored: this saves into STATE_SLOT and the caller reads the effective slot back off state_slot.

Load the broker's slot over the hotkey and confirm PPSSPP read the state back.

The hotkey is silent on an empty slot, so an absent file has to be caught here or the caller reads a no-op as success. A hotkey that was sent is no proof either: PPSSPP swallows one that lands on an unfocused window or a core still registering HLE modules, so the state's access time is backdated first and the load only counts once a read has moved it. The deserialize that read starts is unobservable, and LOAD_SETTLE covers it rather than handing the caller a session mid-restore.

Return the newest state file in the broker's slot, or None when it holds nothing.

Empty the state tree and the memory stick saves before the restore.

A state is named for the game it was taken from, and the game id only comes off the running disc, so a leftover cannot be told apart from the state of the game about to boot. Anything still here belongs to a session that has already exited and whose states RomM holds.

The staging files go with them. A session killed mid-save leaves one behind with no state to pair it against, and the save archive sweeps up whatever sits in the state tree, so it would ship to RomM as a state of its own. So would a .jpg whose state is already gone.

SAVEDATA is cleared for the stronger reason: it is the memory stick, the player's actual in-game progress, keyed by game id with nothing in the path naming whose session wrote it. PPSSPP has no whole-card route to move it on, so the archive is the only thing that should ever put a save there, and a directory the last player left would otherwise be loaded by this one and ship back out in their dump.

Map a pushed state's filename to where it may be written.

With the slot already holding a state, a pushed name has to match it; otherwise the game id is taken on trust, bounded to a <game>_<slot>.ppst basename in the state dir.

Declare what PPSSPP takes: PSP save folders, and one state with its screenshot.

Every folder under SAVEDATA is a unit that must hold PARAM.SFO, the file PPSSPP lists a save by. The state rides the archive and resumes through save.resume_slot.

Place one declared member: a save folder's file under SAVEDATA, a state in the slot.

Refuse a screenshot whose state is not in the plan.

Take the session's product code from RomM; a PSP image is not read for one.

Save a state if asked, then stop the emulator.

Invalidate any in-flight deferred state load before the kill.