Skip to content
PS5PCEM
PartialFirmware and HLE

HLE, high-level firmware emulation

HLE is how PS5PCEM answers the firmware calls a title imports. Each numeric NID becomes a Zig function on a host stack, with the guest System V calling convention preserved on Windows.

Repository notes through October 10, 2026

Why the firmware is not in the game

A PlayStation 5 title does not carry the operating system it calls. Its imports are 11-character identifiers. PS5PCEM computes each identifier from the export name: SHA-1 of the name plus a fixed salt, then the first eight digest bytes in a base64 variant. An implementation registers under the readable name and can require the identifier that name must produce, so a misspelled export fails when the module is built.

The dynamic linker looks the identifier up together with the library, the module and their versions. The same identifier can exist in more than one library. A lookup by identifier alone exists for imports that carry no usable metadata, and that fallback is treated as a last resort because it is ambiguous.

The call runs on a host stack

The guest calls firmware directly, so the call begins on the guest thread's stack, often one megabyte because that is what the title requested. Host work such as opening a file needs a much larger frame. The compiler reserves that frame on entry, before any early return. A firmware body can therefore walk off the guest stack before it reaches the line that needed the space, and the fault lands outside every guest mapping.

Every HLE call switches to a per-thread host stack for the duration of the host work. Arguments travel through memory, so one assembly stub serves every signature, including floating-point and aggregate returns. Nested firmware calls stay on the stack the outer call already established. On Windows the guest uses the System V AMD64 convention while the host uses Microsoft x64, so every guest-callable function is declared with the guest convention. Leaving that declaration off still compiles, and then reads the arguments from the wrong registers.

What the HLE surface covers

On top of that machinery the firmware libraries supply direct and flexible memory, module handles, pthreads, synchronization, files, savedata, fibers, fonts, PNG, the clock, pads, AudioOut, AJM, NGS2, ACM, AvPlayer, APR and AMPR. Network, SSL and the NP Web API keep their context and request lifetimes and return deterministic offline errors. Dialogs that need a system shell finish immediately with a coherent headless result.

The October 10 validation run passed the full ReleaseSafe HLE suite, 606 of 606 tests. That count is the firmware suite. It does not by itself record a new frame rate or a new completed playthrough.

What is implemented

  • NID calculation, a versioned symbol registry and a host-stack switch for every firmware call.
  • Guest System V calls on Windows, where the host convention is Microsoft x64.
  • Memory, files, threading, savedata, media, audio codecs and the APR/AMPR command path.
  • Headless dialogs and an offline network profile that does not open host sockets.

What is still missing

  • Libraries the title imports and PS5PCEM has not implemented still fail the import.
  • Truly on-demand loading of a module that was not in the published graph returns an error.
  • Platform services that need a real shell, account or network peer stay unavailable.

Related mechanisms

What these pages are

The text follows the architecture notes and the October 2026 reports in the PS5PCEM repository. A focused test passing is not a new frame rate and not a new playthrough.

All technologies