ProjectPSX, a C# PlayStation emulator written to learn the hardware

A hardware study that happens to boot games

ProjectPSX is a PlayStation emulator written in C#, and the README is unusually candid about its purpose. It calls itself a personal project whose scope is to learn about hardware and the development of emulators, and it notes that it uses no external dependency and rather simplistic C# code. That framing matters for how you read the rest of the page, because the feature list below it reads as a hardware inventory rather than a consumer feature set.

What is implemented covers most of the console's blocks. The CPU is a MIPS R3000A with Coprocessor 0 and the Geometry Transformation Engine coprocessor. A BUS interconnects the components. The GPU has all its commands implemented, with rendering done by a software polygonal rasterizer rather than a graphics API. The CDROM implements the common commands, DMA transfers and timers are there, and the digital controller is supported but hardcoded to the keyboard. There is a basic BIOS, a MIPS disassembler, MDEC video decoding for 16 and 24 bpp FMV, a display screen with 24 bpp support, memory card support, and an SPU without reverb.

The list of what is not implemented is short but load bearing: DMA resumable transfers and proper CDROM timings. Both of those show up in the FAQ as the usual reason a game gets stuck on the insert game here screen, and the FAQ also names incorrect implementations of the same hardware as a cause, not just missing ones.

The architecture came from a documented source. The author credits Martin Korth's PSX-SPX documentation of PlayStation hardware as the main reference, and the people in the playstation channel on the emudev Discord as helpful.

A headless core with two shells bolted on

The code layout is the practical detail for anyone who wants to build on it. The core is a headless library with no dependencies, and the solution ships two additional projects: ProjectPSX.WinForms and ProjectPSX.OpenTK. The WinForms project uses NAudio for sound output, and the OpenTK project runs on Linux.

The two front ends behave differently, and the difference is in how you load a game. The WinForms version opens a file dialog on execution, where you select a BIN file (track 1 is the one to use) or a CUE file, and the CUE is used to generate the CD tracks that feed the emulated CDROM. The OpenTK version skips the dialog entirely and takes a drag and drop of a bin or cue file onto the window.

The WinForms choice was for speed of prototyping rather than taste, and the UI is now detached from the core, so the author says any windowing system can be added as long as the IHostWindow interface is implemented. That is the extension point to look at if you want a different front end, and the OpenTK project is the existing proof that it works.

The repository root is minimal by design: a ProjectPSX.sln file, the three project directories, a licence and a README. There is no test project, no CI configuration visible at the top level and no tagged release, so the build story is a Visual Studio solution you open yourself.

The BIOS is hardcoded on the BUS class

A valid PlayStation BIOS is required to run the emulator, and the BIOS and expansion files are hardcoded in the BUS class. SCPH1001.BIN is the default used during development, and the README reports that other images such as SCPH5501 or SCPH7001 have worked for other people. In other words, there is no configuration file for the BIOS path; it is a constant in the source, so pointing the emulator at your own dump means editing code.

The same hardcoding pattern shows up in the memory card, where files are hardcoded to memcard.mcr in the root directory, and if no such file exists a new one is generated on save. That is a single fixed file name rather than a per-game card, so if you are testing several games you are overwriting the same save slot each time.

There is also a debugging dimension to the UI. One of the two screenshots shows a window with unusual colors and a doubled game screen, and the FAQ identifies that as the VRAM viewer, which displays the textures, color lookup tables and display buffers used by the software. It is toggled with the TAB key.

For people who want to see what the machine is doing at the instruction level, the FAQ gives two hooks: the CPU main loop has a bios.verbose() function and a TTY() function that can be uncommented to get console and BIOS output, and the same loop can call dissasemble() to print the MIPS instructions and printRegs() to show the current opcode. These are the seams a person learning the hardware would spend the most time in.

Input is a fixed keyboard map, not a controller emulation

Once the machine boots, input is mapped to the keyboard in a table with no configuration. The directional pad goes to the arrow keys, the face buttons map to W, A, S and D in the PlayStation order, Start is Enter, Select is Space, and the shoulder buttons are Q, E, 1 and 2 for L1, R1, L2 and R2.

That mapping is worth reading carefully rather than assuming a WASD convention, because the face buttons are not where most people expect them. Triangle is W, Square is A, X is S and Circle is D.

The controller support is described as digital and currently hardcoded to the keyboard, so there is no analog stick handling, no pressure sensing and no rumble. Given that the input device is the layer the emulator has the least of, an action game with analog control is a poor test of it.

The compatibility section gives the games the author tried that worked, which is the closest thing to a compatibility list in the project:

Ridge Racer, Castlevania Symphony of the Night, Final Fantasy 7, Crash Bandicoot 1, 2 and 3

That list continues with Spyro the dragon, Tekken 1, 2 and 3, Toshinden, Time Crisis, Tobal 1 and 2, Vagrant Story, Street Fighter Zero 3, Rockman/Megaman 8/X4, Parasite Eve, Metal Gear Solid and Crash Team Racing. The README says there is no compatibility list and that many games boot and go in game although some have random problems, and it names Final Fantasy IX, Gran Turismo, Resident Evil 3 and Marvel vs Capcom as titles that boot but have problems to be fixed.

The author says you can play, but should not

The Quick FAQ opens with a question and an answer that are worth reading in full, because they set the expectations for everything else. The question is whether the emulator can be used to play, and the answer is yes but you should not, on the grounds that there are many more capable emulators out there, that this is a work in progress personal project with the aim of learning about emulators and hardware implementation, and that it can and will break during emulation because there are a lot of unimplemented hardware features.

That is the honest position and it matches the rest of the page. The BIOS being a hardcoded constant, the single memcard.mcr file, the missing CDROM timings and the keyboard-only controller all point the same way: this is a codebase to read and tinker with.

The project fits into a sequence. The author lists earlier projects, a Java Chip8, a C# Intel 8080 CPU implementation used for Space Invaders, and a Nintendo Game Boy project, and explains that the PlayStation was the next step because they wanted to move on to 3D and the console had a good library of games. The FAQ also carries a personal note about starting from a job unrelated to coding and studying to change careers, which explains the pedagogical framing.

The licence is MIT and the repository is not archived, with the last push on 2026-07-13 and no GitHub releases. For a project like this, reading the source is the intended use, and the documentation link to Martin Korth's site is the recommended companion.

Editorial conclusion

ProjectPSX is worth reading if you want to see how PlayStation hardware is emulated in readable C#, since the BUS class, the software rasterizer and the hardcoded BIOS handling make the architecture visible, and the author links the Martin Korth hardware documentation he used. It is the wrong tool for playing, because the author states plainly that there are more capable emulators and that this one will break, and it is the wrong tool for anyone who needs a complete implementation, since CDROM timings and resumable DMA transfers are listed as not implemented. Before trying it, get a valid PlayStation BIOS, since SCPH1001.BIN is the default and the BIOS path is hardcoded in the BUS class, and expect the memory card to be written to a file called memcard.mcr in the root directory. The last push was on 2026-07-13 and the repository has no tagged releases.

Frequently asked questions

Official sources

1. BluestormDNA/ProjectPSX on GitHub
2. Issues
3. License: MIT
4. README