The codebase map & the toolbox

Read src/ by responsibility: shared host utilities, loading and linking, guest kernel services, HLE libraries, graphics and the launcher. These are not a strict dependency hierarchy; use the actual includes, callbacks and call sites to trace how two subsystems cooperate.

The map of src/

src/main.cpp, emulator.cpp     the entry: parse args, boot, run
src/common/                   everything independent: abi, logging, threads, file,
                              virtual memory, singleton, debug, host exceptions
src/loader/                   ELF/SELF loading, the runtime linker, NIDs, JIT stubs,
                              guest instruction patching and red-zone protection
src/kernel/                   the guest OS surface: memory, address space, threads,
                              event queues, semaphores, filesystem
src/libs/                     the HLE libraries — topic C5's translation table
src/graphics/                 the GPU half: guest formats, Vulkan host, shader recompiler
src/launcher/                 the Qt launcher that finds games, runs the emulator, checks for updates
tests/                        29 portable test executables, plus x86-64 macOS SSE4a — topic C3

Within graphics, four directories separate guest commands, host rendering, shader compilation and presentation:

The entry points and boot sequence

The main boot responsibilities follow this sequence, as shown in the Lifetime animation. Follow the source for initialization and error paths between these steps:

main.cpp
  └─ ParseArgs()                    --game, the flag table from topic C3
  └─ Run(options)                   emulator.cpp
     └─ Init(...)                   the subsystem sequence from topic C5
     └─ MountSandboxDirs()          /app0, /temp0, ... — topic C5
     └─ LoadElf(eboot.bin)          runtimeLinker: parse SELF/ELF, dynamic tags
     └─ Execute(...)                emulator.cpp — spawns the guest thread
        └─ RuntimeLinker::Execute() load libc if present, resolve relocations, apply patches,
                                    start libc if loaded, call the entry point (topic C2's asm)
     └─ Graphics::WindowRun()       main thread runs the window/event loop

Three files cover most "where does this happen" questions: emulator.cpp (the sequence), loader/runtimeLinker.cpp (the loading/execution), and common/subsystems.h (the lifecycle machinery that runs each step).

The toolbox — third-party libraries

Dependencies in 3rdparty/ come from submodules, configure-time downloads and prebuilt packages; the CMake list in the root CMakeLists.txt is the dependency manifest. The ones you will actually touch:

Two of them are the pair you saw in topic C2 and the patcher topics from the course: Zydis reads the guest's x86 instructions, and xbyak writes new ones. The emulator's own JIT in loader/jit.h is hand-assembled bytes; xbyak is the "proper" assembler used where a lot of code has to be generated.

Reading conventions that save time

• Names map to hardware. pm4.h, gpu_defs.h, RegisterDefaults — if a name looks like a datasheet field, it is one. The codebase keeps console names rather than inventing friendly ones (the path.html appendix covers this in detail).
• Check linkage and registration separately. Namespace-scope static functions and anonymous namespaces provide internal linkage. An HLE function can still be registered by address through LIB_FUNC; header declarations and namespace membership alone do not tell you whether the guest can call it.
• EXIT_IF/EXIT = the error channel. Topic C3's macros. A wall of them at the top of a function is a validation contract.
• Follow a value, not a call graph. Start from a struct (a V#, a Submission, a KernelEvent) and grep for it — the tree is organised around data, and the data names are stable.