How a PlayStation 5 emulator actually works

Start here. Everything else on this page is one of these eight boxes opened up.

The thing to notice is that no step in that chain is a function call the emulator can intercept. The game writes command packets into memory it owns, then hands over a pointer. Everything after that is Kyty reading those packets and rebuilding the work in Vulkan.

The PS5's processor is an 8-core AMD Zen 2 running x86-64 — the same instruction set as your PC. That single fact reshapes the entire project.

So KytyPS5 is not a simulator that steps through the game. It is a host environment the game runs inside — closer in spirit to Wine than to Dolphin. The emulator only regains control when the game calls a function it provides, or when the hardware raises a fault.

Machine code has no concept of a "function argument". Which register carries which parameter is a convention — and the PS5 and Windows disagree about almost all of it.

System V variadic calls carry the vector-register count in al. guestPrintf.cpp interprets guest format strings and arguments explicitly; passing that argument list to the host's vprintf would violate the calling convention.

Two instruction patterns in PS5 code cannot execute on Windows. With no recompiler in the pipeline, the loader rewrites the bytes in place — before the code is ever run.

You can watch this happen for real. Run any title, grep the log for Patch tls at addr, then look at those nine bytes in a debugger: the file on disk has 64 48 8B 04 25 00 00 00 00 and memory has 48 E8 … 48 89 C0. Seeing it once makes the whole mechanism concrete.

Because there is no code generation step, the emulator cannot instrument guest code. The CPU's own fault mechanism becomes the hook — and two of the handler's three branches are deliberate design.

Console software hard-codes addresses and assumes allocations land in particular ranges. It also hands pointers to the GPU. So Kyty claims whole bands of the host address space up front and allocates inside them itself.

Three ways a game asks for memory, and Kyty models each separately: direct memory is a physical reservation that gets mapped as a second step; flexible memory comes from a fixed per-title budget; pooled memory is reserve-then-commit with a batch interface. On top sit sceKernelVirtualQuery — which forces real bookkeeping, since the guest can ask what protection, type, and name a range has — plus PRT apertures for sparse textures.

A mismatch that sounds like a footnote and turns out to shape the whole coherency design.

The hardest problem in the project. A console has unified memory, with guest ordering and cache operations. On a PC, every shared resource is a copy that can go stale — and nothing tells the emulator when it does.

The code is unusually defensive about this, and the reason is worth internalising: a coherency bug produces corruption many frames after its cause, with no traceable link. So each invariant becomes an immediate crash instead — re-entering the tracker from inside an upload callback is a hard failure, and an invalidation that leaves GPU-owned pages behind aborts on the spot.

A PS5 executable is a SELF: a signed container wrapping standard ELF64, with Sony's own segment types and dynamic tags bolted on.

PS5 modules do not export readable names — they export hashes. Resolution is where the emulator inserts itself into the game.

The single most important mechanism in the project, and it hinges on one pointer.

Before implementing an unresolved NID, establish its arguments, outputs, lifetime and error contract from evidence. Register a justified implementation and test ordinary, boundary and error behavior. Removing a stub message or returning OK does not prove the guest-visible behavior is correct. Follow the first-change lesson and contribution capstone. Two ways it silently fails: one wrong character in the NID string, or a LIB_VERSION whose library or module version does not match what the game imports.

Three actors, three completely different jobs, and a separation that is required rather than stylistic.

Guest threads are real host threads, but with two pieces of state Kyty maintains itself: a guest stack allocated inside the guest bands, because guest code computes addresses relative to it and may hand them to the GPU; and a per-thread copy of every loaded module's TLS image, allocated lazily and freed through the game's own allocator if it installed one.

One graphics queue plus seven compute pipes of eight, mirroring the hardware — because games rely on that topology for asynchronous compute.

The game never calls a draw function. It builds raw command packets — the same binary format a real AMD command processor reads — and submits the buffer. So Kyty implements a command processor in software.

Beyond register writes and draws, a real command processor has mechanisms Kyty has to model too: two engines (drawing and constant) synchronised by counters, a 48 KB constant-RAM scratch area, end-of-pipe fences, indirect buffers that work like calls, predication that makes packets conditional, and blocking waits that suspend a submission rather than spinning.

A GPU does not run one shader invocation at a time. It runs 32 or 64 in lockstep on one instruction stream — which means branching cannot work the way you expect.

About 28,700 lines of compiler: explicit decode/CFG/translation frontends, one typed SSA-capable IR and its passes, then the SPIR-V backend.

Structurisation failure is a supported outcome. An irreducible graph, or a graph for which merge and continue blocks cannot be recovered, selects the dispatcher: one loop around a switch on a program-counter value, each basic block a case. Slower, but explicit and diagnosable.

On RDNA 2 there are no texture slots. A shader holds its resource descriptors in registers, or loads them from memory itself — so the emulator has to evaluate the shader's own address arithmetic before the shader ever runs.

Guest memory holds swizzled data; Vulkan wants something else. Converting between them is address arithmetic plus a compute shader per layout family.

A game does not present a frame. It registers buffers, renders into one, and asks the display to scan it out at the next vertical blank.

Every animation on this page, what it explains, and where the prose version lives.