Byrgenwerthnotes of Paleblood, rebuilding Bloodborne one verified function at a time

Last updated: October 7, 2026

Runtime

Paleblood is a decompilation with its own runtime. The decompilation rewrites the game's code, function by function, as readable C++ that is proved to behave like the original. The runtime is what that code, and the original executable while it is being replaced, runs on: Paleblood's own loader and its own versions of the PlayStation 4 system libraries, written from public documentation and our own reverse engineering, not taken from any emulator.

The game does not run on Paleblood yet. It will once the runtime is far enough along the roadmap below. Until then, every replaced function is checked in the verification harness, which runs the original function and the replacement side by side on recorded and generated inputs.

Roadmap

The order the runtime is built in. Each step is measured by how far the game's own executable boots on it.

  1. Loader (done). Maps the executable, applies its relocations and binds every system import, either to the game's own bundled modules (its C library and file system library, mapped as guest code) or to the runtime. The verification harness uses it too.
  2. Generic capture. Recording a function's inputs from the runtime side, with no recording code inside the replaced functions, so new recordings of real play come from the runtime.
  3. Kernel, threads and memory. Processes, threads, mutexes and other synchronisation, memory mapping, time.
  4. Files. Save data, the game's packed archives, its file system library's needs.
  5. Input. Controllers and the signed-in user.
  6. Audio. Audio output and the decoders the game uses.
  7. Video out. Display buffers and flips.
  8. GNM and shaders. The GPU's command interface and the game's shaders: the largest part. Graphics are rebuilt at the level of the game's own graphics layer, not by emulating the console's GPU.

Where the boot stops today

The boot harness runs the executable's entry on the runtime and stops at the first system function the runtime doesn't implement yet, naming it. Implementing that function is the next step of the runtime's work; the boot then gets a little further.

Boot status
The executable's system imports 686
Provided by the game's own modules (mapped as guest code) 219
Implemented by the runtime 19
Remaining 448
Furthest boot milestone loaded (0 of 8)
The boot stops at scePthreadAttrGetaffinity (libkernel), called by the game's own libc module while it starts

Generated by tools/gen_runtime_status.py from a run of Paleblood's boot harness. Do not edit.

Measured with the boot harness in the code repository (runtime/boot.c, tools/boot.py). The work is split into claimable issues per system call group, labelled runtime. The boot milestones, in order, are the first calls to the system's threads, files, input, audio, video out, GPU submission and the first flip.