# Rustation: a PlayStation emulator written in Rust, now superseded > Rustation is a monolithic PlayStation emulator core written in Rust with a GDB debug backend on port 9001, and its author has moved development to a second repository after deciding to restart from scratch. It suits someone studying emulator architecture in Rust, and it does not suit anyone who wants a finished emulator. **simias/rustation** — Playstation emulator in the Rust programing language - Repository: https://github.com/simias/rustation - Stars: 586 · Forks: 22 - Language: Rust - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/simias-rustation ## The readme tells you to use a different repository The first words of the readme are a status notice, and they should shape your whole reading of the project. This project is no longer being developed. The author decided to restart from scratch to fix some architectural flaws in Rustation, and while some of the code was imported into the new repository, other bits were thoroughly rewritten. The new repository is rustation-ng, and the readme says it is now more advanced than this one, with proper sound support and generally more accurate emulation. There is one significant difference between the two projects, that rustation-ng dropped the GL renderer in favor of a threaded software renderer. The GL renderer of Rustation has been ported to C++ and integrated into the Beetle PSX emulator, so it is not completely dead. The repository itself is not archived and the last push was on 2026-06-16, and there are no GitHub releases attached, so the code in the tree is what the author left behind rather than a maintained release line. ## Only the emulator core is here, and it is deliberately monolithic This repository contains only the source code for the core of the emulator. The OpenGL renderer and the libretro interface are in a separate repository, rustation-libretro, which tells you something about the layering. What remains here is a library crate, since the Cargo manifest sets the crate type to rlib and gives the package version as 0.0.3, with the author listed as Lionel Flandrin. The manifest also has a comment that the version should match the latest git tag, and that the version information is used to set an internal VERSION string if git describe is unavailable, which is a build script at work. The design philosophy is stated plainly in the readme: the focus is to write code that is clean, accurate and hopefully easy to understand, and there is no plugin infrastructure because the emulator is monolithic. That is a deliberate choice for a learning-oriented project, and it is the opposite of how a mature emulator splits rendering, input and core emulation. ## The implemented subset is roughly half a PlayStation The list of what exists, even partially, is a useful map of the difficulty order. The CPU is there, along with basic GTE support ported from mednafen PSX, an instruction cache and interrupts. The GPU is basic, with no semi-transparency or mask bit emulation. Timers are incomplete, DMA is present, and there is a debugger. The CDROM controller is there but missing many commands, and the gamepad controller supports only a digital pad. The todo list names the gaps in the same order: many things in the GPU, MDEC, the SPU, the memory card, CPU pipeline emulation and more accurate timings, followed by the author's own summary that there are many, many other things. The two hardware blocks that matter most for a PlayStation are the SPU for audio and MDEC for video decoding, and both are still on the list, which explains the readme's note that a few games boot at all. ## Building needs a PlayStation BIOS you already have The build section names the requirements: Rust and its package manager Cargo, SDL2, and a PlayStation BIOS. The emulator is mainly tested with BIOS version SCPH1001, and the readme gives its SHA-1 as 10155d8d6e6e832d6ea66db9bc098321fb5e8ebf so you can confirm you have the right image. The build itself is one command. ```bash cargo build --release ``` The readme is emphatic about the flag, since without the release optimizations the resulting binary is described as absurdly slow. Running the emulator passes the BIOS path as an argument. ```bash cargo run --release /path/to/SCPH1001.BIN ``` Escape exits the emulator, and Pause/Break breaks into the debugger. For Windows there is a separate issue referenced in the readme. The dependency set in the manifest is small and tells you the era: shaman at 0.1 for the BIOS image format, log at 0.3, arrayvec at 0.4, rustc-serialize at 0.3, an optional lazy_static behind a trace feature, and a path dependency on a cdimage subcrate that is also a top level directory in the tree. ## GDB over TCP 9001, with a set of ready made commands The debugger is the feature that makes this project worth reading for a systems programmer, and it works in an unusual way. You need a GDB targeting mipsel-unknown-elf, and once the emulator is running you press Pause/Break to trigger it, then connect GDB to it. The readme notes that GDB might complain about not finding symbols or the boundaries of the current function, and that you can ignore that. The example session is given as a set of commands with comments. ``` # Dump the CPU registers info registers # Disassemble 20 instructions around PC disassemble $pc-40,+80 # Display word at address 0x1f801814 (GPU status) x/x 0x1f801814 # Add code breakpoint at address 0x00004588 break *0x00004588 # Add write watchpoint at address 0x1f801070 (IRQ ack) watch *0x1f801070 # Step over a single instruction stepi # Continue until a break/watchpoint is reached (or Pause/Break is pressed) continue ``` The addresses in the comments are the interesting part, since 0x1f801814 is the GPU status register and 0x1f801070 is the interrupt acknowledgement register, so the examples double as a map of the memory map. The author describes the debugger support as pretty experimental and quirky, but says it works for basic debugging needs. ## A LaTeX guide, hardware tests and the No$ specifications The author is also writing a document about the process of writing the emulator itself, in LaTeX, published in the psx-guide repository. The readme is honest that the document is generally lagging behind the actual code, and that it will be updated as often as possible. The testing approach is equally concrete, because the author runs tests on real hardware and stores them in the psx-hardware-tests repository. For sources, the readme names the No$ PSX specifications as the primary reference and says mednafen's source code is used when the author feels like cheating. That combination, official style hardware documentation for the specification, an existing emulator's code for reference, and real hardware for ground truth, is a reasonable methodology for an accuracy-focused emulator, and it is the reason the successor project can claim more accurate emulation. The last section also points at a board on 8chan for less formal discussion of the emulator and PlayStation topics in general, with the author noting that will see if this turns out to be a good idea. ## Conclusion Rustation fits a developer who wants to read emulator internals in Rust rather than C, since the CPU, GTE, DMA, timers and debugger are all legible in a monolithic codebase, and it fits anyone who wants to attach GDB to a running PlayStation emulation. It does not fit a user who wants to play games, since the author says performance is poor, only a few titles boot, and the successor project is already more advanced. Before you build it, expect to follow the successor, because the readme states this project is no longer being developed and points to rustation-ng, and note that the GL renderer and libretro interface live in a separate rustation-libretro repository rather than here. ## FAQ ### Is Rustation still being developed? No. The readme states that this project is no longer being developed, because the author decided to restart from scratch to fix architectural flaws. The successor is the rustation-ng repository, which it says is more advanced, with proper sound support and more accurate emulation. ### How do I build and run the Rustation emulator? You need Rust with Cargo, SDL2 and a PlayStation BIOS, and the emulator is mainly tested with BIOS version SCPH1001 whose SHA-1 is 10155d8d6e6e832d6ea66db9bc098321fb5e8ebf. Build with cargo build --release, then run it with cargo run --release and the path to the BIOS file. ### What can the Rustation emulator actually run? Very little. The readme says it can only boot a few games, with Crash Bandicoot in the Japanese version mostly playable although with random crashes, and some other games such as Spyro freezing during or after the intro. The SPU, MDEC and memory card are still on the todo list. ### How do I use the Rustation debugger? Press Pause/Break while the emulator is running, then connect a GDB targeting mipsel-unknown-elf over TCP port 9001. GDB may complain about missing symbols or function boundaries, which the readme says you can ignore, and the debugger support is described as experimental and quirky. ### Where is the renderer for Rustation? Not in this repository. This one holds only the emulator core, with the OpenGL renderer and the libretro interface in the separate rustation-libretro repository. The successor project rustation-ng dropped the GL renderer in favour of a threaded software one. ## Sources - [Issues](https://github.com/simias/rustation/issues) - [README](https://github.com/simias/rustation/blob/master/README.md) - [simias/rustation on GitHub](https://github.com/simias/rustation) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/simias-rustation