* [HLE] Answer POSIX host memory queries without the mapping lock Every HLE import that reads stack arguments queries the guest stack's protection first. On POSIX the query took the same lock Protect holds across its mprotect call, and GPU write tracking protects pages constantly, so each query waited tens of microseconds; Silent Hill: The Short Message spent up to a second of every five seconds in queries. Regions are now also published as an immutable snapshot (replaced under the lock when a region is added or removed), and a query of untracked memory or of a region without per-page overrides is answered from it without the lock. Regions with overrides keep the locked path, which now finds where a protection run ends through an ordered set of overridden pages instead of visiting every override (write tracking leaves tens of thousands), and the next region by binary search. Query time drops from 200-1000 ms to 5-50 ms per 5 s. This is the POSIX counterpart of replacing page-by-page VirtualQuery scans on Windows. (cherry picked from commit b6ffe31f28fa93842726b71315c7731f97b5fda8) * [Cpu] Sleep through nanosleep, resumed on EINTR, in the POSIX Sleep stub The POSIX stand-in for kernel32!Sleep (which the native sceKernelUsleep intrinsic calls with milliseconds) converted to microseconds and called usleep. macOS rejects usleep(>= 1 s) with EINVAL and returns at once, so every guest sleep of a second or more came back immediately; and a signal (the runtime's thread activations, for one) ended any sleep early through an error the stub never looked at. The stub now builds a timespec and calls nanosleep, and when nanosleep returns EINTR it resumes with the remaining time. A test exercises the stub with the Win64 argument register for both a 1.2 s and a 20 ms sleep. (cherry picked from commit 43b770f86b5e3aa2332121f1bc2ddf2acc9d2968) * [HLE] Query POSIX view regions from a lock-free snapshot Every HLE import first queries the guest stack's protection, and the view-region query took the same gate the GPU write tracker holds across its mprotect calls, so each import waited on page-protection traffic from other threads (the main guest thread spent ~2% of its time in that wait at Silent Hill: The Short Message's menu). The region list is now also published as an array snapshot whenever it changes, and queries read the snapshot without the gate. Per-page protections already changed in place and were read racily; nothing changes there. (cherry picked from commit d7e72cb4974388883696516420b2e9d462778715) * [Cpu] Skip the scheduler gate when a host thread re-registers the same guest context scePthreadSelf on a guest thread the scheduler does not own registers the thread's context on every call, and that took the scheduler-wide gate each time - tens of thousands of times a second on Silent Hill: The Short Message's main thread, contending with the dispatcher and every blocked-thread wake. Each host thread remembers the handle and context it registered last; a repeat registration only refreshes the external-handle hint and returns. New or changed registrations still take the gate. (cherry picked from commit d1991b2b75261cd1f1ccb4e005b10805f0da24c1) * [Cpu] Keep each thread's guest continuation stub instead of mapping one per resume Every resume of a blocked guest thread allocated a 512-byte executable stub page and a host-RSP slot, and released both when the thread blocked again: an mmap/munmap pair plus two acquisitions of the host-memory gate per resume, which the GPU write tracker holds across its own protection changes. Contended on that gate, resumes were 62% of all lock waiting in Silent Hill: The Short Message's menu. Each host thread now keeps a stub page and slot per nesting depth for its lifetime; a resume reopens the page for writing with mprotect directly (the page is emulator-private, so it bypasses the tracked host-memory layer), re-emits the stub and seals it again. Lock waiting across threads halves (13.6 s to 6.5 s per 30 s). (cherry picked from commit 2c2293abdd5d19dd1be3d6941dcedf9b482c6420) * [Kernel] Round host condvar waits up to whole milliseconds Monitor.Wait truncates its timeout to milliseconds, so a timed wait with less than 1 ms left became a zero timeout and spun until the deadline. UE's game thread waits for the render fence in 1 ms slices, which kept a host core busy for the whole wait and contended the condvar lock with the signaling threads. Timed waits may wake late, so round up instead. SH menu 4.29 -> 4.64 fps together with the readback retry change. (cherry picked from commit 66eaa0095fe594ff8e285cbf31c32bd84274ac85) * [Tests] Run the POSIX Sleep stub test only in x64 processes The stub is x86-64 machine code; a native arm64 test host cannot map or run it, so the macOS arm64 CI runner failed to allocate the stub page. |
||
|---|---|---|
| .github | ||
| LICENSES | ||
| assets/images | ||
| docs | ||
| scripts | ||
| src | ||
| tests | ||
| tools | ||
| .editorconfig | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| Directory.Build.props | ||
| Directory.Packages.props | ||
| LICENSE.txt | ||
| README.md | ||
| REUSE.toml | ||
| SharpEmu.slnx | ||
| global.json | ||
| nuget.config | ||
README.md
SharpEmu
An experimental PlayStation 5 emulator for Windows, Linux and macOS.
Join our official Discord server for development updates, compatibility discussions, support, and community chat.
[!IMPORTANT] Official channels: Only sharpemu.app and the links listed in this GitHub repository are affiliated with SharpEmu. Any other websites, accounts, or donation pages are unofficial and unauthorized.
[!NOTE]
SharpEmu supports Windows x64, Linux x64, and macOS x64. Apple Silicon Macs can run the macOS x64 build through Rosetta 2, and Windows on ARM devices (e.g. Snapdragon) can run the Windows x64 build through Windows' built-in x64 emulation.
[!WARNING]
SharpEmu is an experimental PS5 emulator developed from scratch in C#. The current focus is on accuracy and infrastructure setup rather than game-specific compatibility.
Info
SharpEmu is an emulator project currently in its early stages of development.
This project is developed purely for research and educational purposes. There are no commercial goals associated with it. We enjoy learning about system architecture and reverse engineering.
SharpEmu focuses exclusively on the PlayStation 5.
Our goal is not to emulate PS4 games, as there is already an excellent emulator dedicated to that platform: ShadPS4.
Games Tested
| Demon's Souls Remake | ASTRO BOT |
|---|---|
![]() |
![]() |
| ASTRO's PLAYROOM | Dead Cells |
|---|---|
![]() |
![]() |
| God of War: Sons of Sparta | Tomb Raider V Remastered |
|---|---|
![]() |
![]() |
Status
The emulator can currently load the eboot.bin of real games, execute native CPU instructions, and partially handle gpu-related functionality. Included 3D games.
SharpEmu supports Windows, Linux, and macOS hosts. Video output uses Vulkan on Windows and Linux, and MoltenVK on macOS. Platform support is still experimental, so compatibility and performance vary by game, operating system, and GPU driver.
Using
Download the release archive for your operating system, extract it, and launch
SharpEmu with the path to a legally obtained game's eboot.bin.
Or command line;
Windows PowerShell:
.\SharpEmu.exe "C:\path\to\game\eboot.bin" --log-to-file
Linux and macOS:
chmod +x ./SharpEmu
./SharpEmu "/path/to/game/eboot.bin" --log-to-file
SharpEmu supports environment variables that can be configured from the GUI. Undocumented variables are listed here: docs/sharpemu-gui-undocumented-env-vars.md
You can set them per game or globally in the GUI, or pass them directly through the CLI.
A Vulkan-capable GPU and current graphics driver are required. The macOS release includes the MoltenVK Vulkan implementation.
[!IMPORTANT]
This project does not support or condone piracy.
All games used during development and testing are dumped from consoles that we personally own.
Users are expected to use legally obtained copies of their games.
Build
- Install the .NET SDK version specified in
global.json. - Clone the repository:
git clone https://github.com/sharpemu/sharpemu.git - Open the solution file (
SharpEmu.slnx) in VSCode. - Build the project:
dotnet buildordotnet publish - Build artifacts will be located in the
artifactsdirectory.
Disclaimer
SharpEmu is an experimental emulator intended for research and educational purposes.
This project does not contain any copyrighted system firmware, game data, or proprietary PlayStation assets.
Special Thanks
The following projects were extremely helpful during development:
-
ShadPS4
Helped with understanding the basic architecture of the PlayStation 4. -
Kyty
One of the few PS5 emulator projects available and very useful for studying native code execution. -
Ryujinx
Provided valuable references for filesystem handling and low-level C# implementation patterns.
License
Support
Support SharpEmu via GitHub Sponsors or cryptocurrency. Every contribution helps fund ongoing development and long-term maintenance. GitHub Sponsors is the preferred way to support the project, but cryptocurrency donations are also appreciated.
ETH/USDT
0xF315F5d986c790bB3A58DbE60F1B2760997dEd82
BTC
bc1qmr9k8899njys5ny63xsues4jgmkk96erslrkmv
Contributing
Before opening an issue or pull request, please read our contribution guidelines:
The guide covers:
- Coding style and formatting
- AI-assisted contributions
- Pull request expectations
- Testing guidelines
- Legal and reverse engineering policy





