What an emulator is

An emulator makes one computer behave like another, so that software built for the second runs on the first. That is the whole idea. Everything else is engineering trade-offs about where you cut.

The simplest possible emulator

Imagine a toy machine with four registers and a handful of instructions. An emulator for it is a loop:

uint8_t memory[65536]{}; // load the toy program before executing
uint32_t reg[4]{};
uint16_t pc = 0;
auto fetch = [&]() { return memory[pc++]; }; // 16-bit PC wraps

for (;;) {
    switch (fetch()) {
        case 0x01: { // LOAD reg, little-endian imm32
            const uint8_t r = fetch();
            if (r >= 4) return; // invalid register
            uint32_t value = 0;
            for (unsigned byte = 0; byte < 4; ++byte)
                value |= uint32_t(fetch()) << (8 * byte);
            reg[r] = value;
            break;
        }
        case 0x02: { // ADD dst, src
            const uint8_t d = fetch(), s = fetch();
            if (d >= 4 || s >= 4) return;
            reg[d] += reg[s];
            break;
        }
        case 0xFF: return; // HALT
        default: return;  // invalid opcode
    }
}

This illustrates an interpreter: fetch an instruction, decode it, perform its operation, repeat. A complete implementation also defines invalid instructions, exceptions and every other part of the guest machine.

The loop adds decoding and dispatch work to every guest instruction. Its cost depends on the interpreter, host and workload; CPU clock rates alone cannot predict emulation speed. Caching translated code or executing compatible guest instructions natively can avoid much of that repeated work.

Execution strategies and HLE

What an emulator must actually reproduce

A CPU is only one of the things a program depends on. To run an unmodified console game you must reproduce all of:

1. The instruction set — so the code executes at all.
2. The calling convention — so a function's arguments arrive where it expects them.
3. The memory layout — so pointers, allocations and alignment assumptions hold.
4. The operating system's services — threads, files, memory, timers, networking, audio, input.
5. The GPU — including its command format, its register set, its memory layouts and its shader instruction set.
6. The timing model — vertical blank, frame pacing, audio clocks. Games are full of code that assumes 60 Hz.

Most ordinary guest CPU instructions execute directly in a compatible x86-64 environment. Targeted instruction compatibility is still necessary; the remaining responsibilities account for most of this project.

You cannot emulate what you do not understand. Here is the PlayStation 5, described in the terms that matter to an emulator author rather than to a shopper.

The hardware

The software stack

The PS5's operating system is a descendant of FreeBSD. That heritage shows everywhere in the API surface:

KytyPS5 replaces the middle two layers wholesale with native C++, and models the fourth in software. The game executes natively, with relocations and targeted compatibility patches applied by the loader.

What a game file actually is

A PS5 title directory contains, at minimum:

MyGame/
├─ eboot.bin              the main executable — a SELF (Signed ELF)
├─ sce_sys/
│   ├─ param.json         title ID, version, memory budget, capabilities
│   ├─ icon0.png
│   └─ …
├─ *.prx / *.sprx         optional extra modules shipped with the game
└─ (game data files)

Kyty reads param.json for the title ID and the flexible-memory budget, mounts the directory as /app0, then loads eboot.bin.