How a PlayStation 5 emulator works
KytyPS5 recreates parts of the PlayStation 5 environment on a PC. Its native execution path runs guest CPU code on the host CPU, supplies console services, and translates GPU work. Learn those boundaries step by step, then practice making a small, verified change.
New to C++ or emulation?
Begin with five small lessons: build a C++ program, decode bytes, track ownership, step an invented CPU and distinguish submission from completion. Each has runnable code, expected output, hints and worked answers. You can finish these without a game or an emulator build.
Already know C++? Use the readiness questions to choose your entry point. Follow the core route into loading, HLE, graphics and a verified first contribution.
Source snapshot and advanced implementation coverage
Checked source: d2413fc2ebd91d1b7234197c2dd5bd48e1cb6a51 (7 October 2026). Implementation detail belongs in the owning lesson; browser models are simplified teaching tools.
Ray tracing: Implemented: full-float BVH32/BVH64 software intersections emitted as SPIR-V. Additional formats and an optional Vulkan ray-query backend remain research; the supported subset does not establish universal game compatibility.
Ready to work on the emulator?
The developer curriculum adds end-to-end boot and draw traces, three runnable C++ debugging labs, and evidence-based contribution gates. Its coverage map distinguishes detailed lessons from introductory and still-missing material.
The shape of it
A game module is an ELF no normal loader accepts. It imports functions by NID — short encoded ids, not names.
The runtime linker resolves those ids against hand-written implementations, rewrites a few instructions, and jumps in.
From there the code runs natively. There is no interpreter. The work is faking an OS and a GPU around it.
The GPU path has several additional translation stages. The game writes PM4 command packets into a ring buffer; a software command processor decodes them, turns accumulated register writes into Vulkan pipeline state, and translates compiled RDNA 2 shader binaries into SPIR-V. All the while CPU and GPU share memory each believes it owns, and coherency is held together by catching host page faults — with the guest convinced pages are 16 KB and the emulator's host tracking using 4 KB granularity; actual OS protection granularity is a separate constraint.
What you'll be able to do
- 01Take a command-buffer dump from your own run and read it packet by packet — find the draw, and the state that set it up.
- 02Open a game module and see exactly what the runtime linker sees: the Sony segments, the dynamic tags, the imports it can't resolve.
- 03Verify a bounded HLE behavior with explicit output and error checks before making a compatibility claim.
- 04Explain why a shader fell back to the dispatcher, and what would have to change for it not to.
- 05Read a failing log and tell the difference between a cause and a symptom.
How a topic works
The beginner lessons pair explanations with runnable programs and worked answers. Many project topics add animations and interactive tools. Project C++, subsystem lessons and source checkpoints follow the concepts they build on; each page makes its prerequisites and code-example scope explicit.
The explanation, with code from the tree.
Step the animation by hand.
Change the inputs, watch the result move.
A checkpoint against the source.
Your progress
Use these as alternate reading views and practice tools. The Start here route defines the learning order; the book and tour share generated excerpts with the topic pages.