AnyPS5: an emulation-free port layer for PS5 to PC

⏱️ Reading time: 15 min

Dreaming Sarah, a 2D platformer built exclusively for PS5, runs at a stable 60 fps on a GTX 1050 Ti paired with an i5-7500 at 3.4 GHz. It achieves this without an emulator: AnyPS5 applies an emulation-free port layer that rewrites the console’s executable so it speaks the native language of Windows or Linux.

📑 En este artículo

1. TL;DR
2. What is an emulation-free port layer?
3. AnyPS5: the relinker that doesn’t need a virtual machine
4. How the relinker works: from PS5 executable to native binary
5. Reimplementing the system libraries: what is a PRX
6. The shader recompiler: from GNM to SPIR-V
7. Practical examples: what already runs on AnyPS5
8. Getting started
9. Real-world use cases
10. Common mistakes and best practices
11. Comparison with alternatives
12. Going deeper
13. Frequently Asked Questions
    1. What makes AnyPS5 different from a PS5 emulator?
    2. Does an emulation-free port layer work with any PS5 game?
    3. Why does AnyPS5 need to reimplement the PRX libraries instead of copying them?
    4. What happens if AnyPS5 encounters a system function it doesn’t recognize?
    5. Is it legal to use AnyPS5 with my own PS5 games?
14. References

The technique resembles Proton, the layer Valve uses to run Windows games on Linux without translating CPU instructions: in both cases, the source and target processors share the same architecture, and what changes is the operating system and its libraries. AnyPS5 applies that same logic to a console for the first time, publicly.

TL;DR

• An emulation-free port layer translates the binary once: it doesn’t interpret CPU instructions on every frame.
• AnyPS5 reimplements the PS5 system libraries (PRX) as native code for Windows and Linux.
• Dreaming Sarah runs at a stable 60 fps on a GTX 1050 Ti with an i5-7500 at 3.4 GHz.
• AnyPS5’s shader recompiler converts PS5 graphics code to SPIR-V, validated with Spirv-Tools.
• The GPL-2.0-only license requires that any improvement to the relinker or to a reimplemented PRX stay open source.

What is an emulation-free port layer?

An emulation-free port layer is a software layer that converts an executable from one system to another by rewriting its binary format and replacing the original system libraries with native implementations, without translating CPU instructions in real time the way a traditional emulator does.

The difference compared to an emulator like RPCS3, which replicates the PS3, lies in the CPU architecture. The PS3’s Cell Broadband Engine processor has nothing in common with a PC processor, so every instruction has to be translated in real time. The PS5, on the other hand, uses an APU with AMD Zen 2 cores, the same x86-64 family that runs on any modern desktop computer. There’s no architecture to translate: all that’s left is resolving the executable format and the libraries the game expects to find.

That architectural similarity is the necessary condition for a port layer to work. If the source and target CPUs didn’t match, relinking the binary wouldn’t be enough; it would require a full emulator or, at minimum, a static recompiler that translates each instruction to its equivalent in the target architecture.

AnyPS5: the relinker that doesn’t need a virtual machine

AnyPS5 is an open source project that automatically ports PS5 executables to Linux and Windows. Its GitHub repository had accumulated 7,400 stars, 554 forks, and 103 watchers as of October 7, 2026.

The README sums it up directly. It includes a relinker that converts the executable to the target system’s native format and an implementation of the PRX system libraries needed for dynamic linking, without emulation or a separate runtime process.

The project measures its own progress with a percentage: how many of the system library functions declared in core/libs/prx are already implemented, not how many functions exist in total in the PS5 operating system. That distinction matters because the number grows as more functions get declared, not only when previously known ones get implemented.

The code is distributed exclusively under the GPL-2.0 license, which requires any fork or derivative product to stay open source. That’s exactly the principle behind AnyPS5: an emulation-free port layer applied to a console instead of to another PC operating system.

flowchart TD
    A["PS5 executable"] --> B{"Same CPU architecture as the PC?"}
    B -->|"No, e.g. PS3's Cell"| C["Emulator: translates instructions every frame"]
    B -->|"Yes, PS5 uses x86-64"| D["Port layer: relinks the binary once"]
    C --> E["Simulated native code, constant cost"]
    D --> F["Real native executable, no real-time translation"]

How the relinker works: from PS5 executable to native binary

A PS5 game is distributed in a proprietary Sony executable format derived from ELF, designed so the console’s kernel can load it and resolve its references against the PS5 operating system’s libraries. AnyPS5’s relinker takes that binary and rewrites it as a native executable (a PE on Windows or a standard ELF on Linux), pointing every system function call to the project’s own implementation instead of to the original kernel.

This operation happens only once, before running the game, not on every instruction during gameplay. That’s the practical difference compared to an emulator: an emulator interprets or translates code as it runs, instruction by instruction, which adds a constant computing overhead. AnyPS5’s relinker produces a binary that the target operating system can run directly, with the same startup cost as any native program.

In concrete terms, every reference in the original binary to a system function (for example, a call to read the controller or open a file) gets resolved as a symbol pointing to the address of a function written by the project, not to the address where that function lived inside the PS5 firmware. If that function hasn’t been reimplemented yet, the symbol simply doesn’t exist, and the program fails to load or to call it, instead of producing undefined behavior.

Reimplementing the system libraries: what is a PRX

PRX is the dynamic library format PlayStation consoles have used since the PS3: a loadable module that exposes operating system functions, the same way a DLL exposes them on Windows or a .so does on Linux. When a PS5 game calls a networking, storage, or input function, it’s actually calling a function inside a system PRX.

AnyPS5 doesn’t copy those libraries (it couldn’t: they’re Sony’s property), but instead reimplements each function from scratch, replicating the expected behavior. It’s reverse engineering work done function by function, which is why the project measures it as a coverage percentage: every newly documented and implemented function expands the list of games that can boot without tripping over an unknown call.

When the game calls a function that doesn’t exist yet in that reimplementation, AnyPS5 doesn’t try to guess or keep running with approximate behavior. It throws a std::runtime_error exception, prints the message to standard error, and terminates the process, as documented in the project’s repository.

flowchart LR
    A["PS5 executable"] --> B["AnyPS5 relinker"]
    B --> C["Native binary (ELF or PE)"]
    B --> D["System function calls"]
    D --> E["Custom PRX implementation"]
    C --> F["Native process on Windows or Linux"]
    E --> F

The shader recompiler: from GNM to SPIR-V

PS5 games render their graphics with GNM, Sony’s proprietary low-level graphics API, using shaders compiled for that platform. For those shaders to run on a PC GPU, AnyPS5 includes a recompiler that translates the original graphics code to SPIR-V, the intermediate format used by Vulkan and other modern APIs.

The project can be built with the ANYPS5_ENABLE_SPIRV_TOOLS flag, which validates every recompiled shader against Spirv-Tools, Khronos’s official tool for verifying that a SPIR-V module is valid before sending it to the GPU. There’s no direct way to check from the outside whether a specific shader passed that validation without building the project with that flag enabled, because the result depends on the particular shader each game uses.

💭 Key point: shader translation is the part of the port layer that most resembles partial emulation: the GPU code does get recompiled into another language, even though the CPU binary isn’t translated in real time.

Practical examples: what already runs on AnyPS5

The project’s most cited public proof is Dreaming Sarah, a 2D platformer that runs at a stable 60 fps combining a GTX 1050 Ti with an i5-7500 at 3.4 GHz: mid-range hardware from several years ago, not a latest-generation GPU. That matters because it confirms the port layer’s own overhead is low, since the relinker doesn’t add a constant translation layer that eats up CPU cycles on every frame.

For controls, AnyPS5 supports any controller mapped through SDL, including analog sticks and triggers, and lets you configure keyboard and mouse through an anyps5-input.ini file. It’s the least exotic part of the project: once the executable runs natively, mapping input is a problem that’s already been solved many times in other compatibility projects.

The public list of verified games is still short, which is consistent with a project that grows one PRX function at a time instead of replicating the entire system all at once. The repository itself maintains a separate compatibility list to track which titles boot and with what known issues.

Getting started

AnyPS5 is a C++ project built with CMake and several third-party submodules in the 3rdparty folder, so cloning it has to include those submodules. The README doesn’t spell out in plain text which graphics SDK or compiler version each platform requires, so before building it’s worth checking the repository’s own build instructions, which is the source that gets updated whenever requirements change.

git clone --recursive https://github.com/boykopovar/AnyPS5.git
cd AnyPS5
cmake -B build -S .
cmake --build build --config Release

This flow clones the repository with its submodules, generates the build files with CMake, and compiles in Release mode. It works the same way on Windows and Linux because CMake abstracts the generator (Visual Studio, Ninja, or Make) based on the platform; what changes between systems is the compiler toolchain installed beforehand, not the CMake commands. AnyPS5 also requires a PS5 executable obtained legally by the user: the project doesn’t distribute or require copyrighted software.

Real-world use cases

The README itself frames the project around four uses: interoperability, research, preservation, and compatibility. Preservation is the key word for a console catalog that, like all hardware, eventually stops being manufactured and repaired; a port layer that lets those binaries run on standard PC hardware extends the software’s useful life long after the original console becomes hard to maintain.

Research and interoperability point to a different use: understanding how a closed console’s operating system is built by documenting, function by function, what each part of its system library does. That knowledge, published as GPL-2.0 code, serves this project as much as it serves any other compatibility effort that needs the same information.

⚠️ Heads up: AnyPS5 doesn’t include, distribute, or require Sony firmware, cryptographic keys, or proprietary libraries. Each user is responsible for making sure the binaries they use come from a legal source under their country’s laws and the original software’s license terms.

Common mistakes and best practices

The most common mistake when evaluating this kind of project is comparing it to an emulator in terms of compatibility expectations. A mature emulator like RPCS3 has spent over a decade replicating a console’s full behavior instruction by instruction; AnyPS5 grows one reimplemented function at a time, so the list of titles that boot without errors is still short and depends on how many PRX functions are covered.

Another misunderstanding is assuming that if a game runs, it runs completely. The project itself documents that any unsupported state throws an exception and terminates the process immediately, with no silent behavior or data corruption slipping through unnoticed. It’s a defensible design decision, but it means a game can progress through several scenes and then close without warning once it hits a function that isn’t implemented yet.

An additional gotcha is assuming any GPU will do. The shader recompiler produces SPIR-V meant to run on Vulkan, so the graphics card and its drivers need reasonably up-to-date Vulkan support; a GPU without that support has no way to run the recompiled shader, no matter how well the rest of the executable is relinked.

Good practice before trying a new game: check the project’s compatibility list and how well covered the libraries that game relies on most (graphics, networking, storage) are, instead of assuming the entire PS5 catalog behaves the same way.

Comparison with alternatives

An emulation-free port layer isn’t the only way to bring software from one system to another. The table compares the four most common strategies and the hardware conditions under which each one makes sense.

Going deeper

Relinking an executable isn’t just about changing the file header. Every system function call uses a calling convention (which registers or stack positions carry the arguments) and a memory layout that the original PS5 kernel expected. The relinker has to preserve that convention on the application side while resolving each symbol against the corresponding native implementation, so the real work lies in mapping function by function, not in a single generic format conversion.

The GPL-2.0-only license is also an indirect technical decision: any improvement to the relinker or to a reimplemented PRX library flows back to the project if it’s distributed, which in theory speeds up the growth of the coverage percentage as more developers contribute new functions to core/libs/prx.

It’s worth repeating the nuance about the coverage percentage: it measures known, declared functions, not the real total surface area of the PS5’s PRX, which Sony never published in full. It’s a useful metric for tracking the project’s progress, but not a promise of what fraction of the console’s catalog will end up running.

This approach also isn’t portable to just any target. If someone wanted to bring the same games to an ARM architecture, like a phone or a handheld console, the relinker alone wouldn’t be enough: that would actually require translating CPU instructions, because x86-64 and ARM share neither an instruction set nor a calling convention. The emulation-free port layer works exactly in the case AnyPS5 applies it to: same CPU family, different operating system.

sequenceDiagram
    participant J as PS5 game
    participant R as Shader recompiler
    participant V as SPIR-V validator
    participant G as GPU via Vulkan
    J->>R: shader compiled for GNM
    R->>V: generated SPIR-V
    V-->>R: validation ok or error
    R->>G: SPIR-V shader ready
    Note over R,G: only validated if built with ANYPS5_ENABLE_SPIRV_TOOLS

Your next step: clone the AnyPS5 repository with git clone --recursive, open the core/libs/prx folder, and count how many graphics or networking library functions are already implemented before evaluating whether your favorite PS5 game has a chance of booting.

Frequently Asked Questions

What makes AnyPS5 different from a PS5 emulator?

AnyPS5 doesn’t interpret CPU instructions in real time because the PS5 and a modern PC share the x86-64 architecture. Instead of emulating, it relinks the executable to the target system’s native format and reimplements the PRX system libraries the game needs.

Does an emulation-free port layer work with any PS5 game?

Not yet. Each game depends on which PRX library functions are already reimplemented; if it calls a function the project doesn’t cover, the process terminates with an exception instead of continuing with approximate behavior.

Why does AnyPS5 need to reimplement the PRX libraries instead of copying them?

Because the original PRX libraries are Sony’s property and can’t be distributed or reused directly. The project rewrites them from scratch, function by function, replicating the behavior games expect.

What happens if AnyPS5 encounters a system function it doesn’t recognize?

It throws a std::runtime_error exception, prints the message to standard error, and terminates the process immediately, instead of continuing with an unsupported state.

Is it legal to use AnyPS5 with my own PS5 games?

The project states it exists for interoperability, research, preservation, and compatibility, and doesn’t include or require Sony firmware or keys. Whether using a specific executable is legal depends on how each user obtained it and the laws of their country.

References

• GitHub: boykopovar/AnyPS5: the project’s official repository, with the README documenting the relinker, the PRX libraries, and the compatibility list.
• Wikipedia: PlayStation 5: the console’s hardware specifications, including the AMD Zen 2 CPU.
• GitHub: ValveSoftware/Proton: Proton’s official repository, Valve’s compatibility layer used here for comparison.
• Khronos Group: SPIR-V specification: the intermediate shader format used by Vulkan and by AnyPS5’s recompiler.
• GitHub: KhronosGroup/SPIRV-Tools: official tools for validating SPIR-V modules.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Anne Nygård en Unsplash