PS4 executables on AnyPS5: first results (a PS4 homebrew runs) and what retail PS4 games would need

[Get-fix]

In #159, boykopovar wrote:

The PS5 supports backwards compatibility with PS4 games, meaning the PS5's system libraries have everything needed to run PS4 games. But this is theoretical; no one has tried it yet.

and, about versioning of system libraries:

So far, there have been no problems with versioning system libraries.

So I tried it. The relinker fixes and the remaining work are tracked in #3093.

Short answer

• Retail PS4 games: not possible today. The main gap is graphics. PS4 games draw through libSceGnmDriver, the PS4 GPU driver. AnyPS5 implements the PS5 one (libSceAgcDriver) and has no libSceGnmDriver.
• A PS4 homebrew that draws on the CPU does run. It needed two relinker fixes, which are ready, plus about nine experimental changes, which are not submitted. As far as I know, this is the first time a PS4 executable has run on AnyPS5.
• A lot is shared. Of Bloodborne's 468 system imports, 308 are already implemented in AnyPS5 under the same NIDs.

What I tested

• Bloodborne (CUSA00900 v1.09): the eboot from my own disc dump. Only measurements are posted here; no game files are shared.
• The OpenOrbis PS4 Toolchain graphics sample: it draws a Mandelbrot set on the CPU straight into the frame buffer. I used their prebuilt sample ELF and packaged it into a PS4 eboot with OpenOrbis create-fself v1.3.
• Setup: Windows 11 with an RTX 5060 Ti, a MinGW build of main at 262c031, and no PS4 hardware.

Two relinker fixes (ready)

1. fix/relinker-sce-dynamic-tables: DT_SCE_* table values are offsets into PT_SCE_DYNLIBDATA, not file offsets.
2. fix/relinker-scan-code-extent: for executables with PT_SCE_DYNLIBDATA, the syscall and call-site scans stop at the end of the PLT. Bloodborne keeps 37 MiB of read-only data after its code, and the scans decoded it as code.

Checks:

• ctest:

  build	result
  main	96/96
  fix 1	96/96
  fix 2	97/97
  both merged	97/97

• New tests: each fails on main and passes with its fix.

• Mutation checks: all six are caught.

• PS5 executables: ps5-doom, VLC and Jelly5 convert byte-identically to main.

Details are in the issue.

Where each executable stops

Relinker only, current main:

	Bloodborne	OpenOrbis sample
main	Dynamic string offset is outside DT_STRSZ	Symbol table entry out of bounds
fix 1	Unsupported 0F 79 opcode without SSE4A prefix (data decoded as code)	RELATIVE relocation has a nonzero symbol index
fix 1 + 2	scans pass (3,522 references); Code analysis: overlapping instruction boundaries (offset 0x3457cf) (inline jump tables)	same as fix 1

The homebrew on screen

With both fixes and the experimental changes below, the sample did the following:

• main() ran and printed Creating a scene and Entering draw loop;
• it registered two linear 1920x1080 buffers;
• the window title showed OpenOrbis graphics sample | FPS: 3.4.

I dumped frames from its display buffer. They match the sample source: only the blue channel varies, the set is black, and every frame is the same. The low frame rate is expected, because the sample recomputes the whole 1920x1080 image on the CPU every frame (Debug build). I haven't compared it with real hardware.

What it needed, in the order it hit them:

1. RELATIVE relocations: OpenOrbis create-fself writes R_X86_64_RELATIVE with symbol index 1, a value-0 STT_SECTION symbol. The relinker rejects it.
2. PT_SCE_RELRO has to be loaded and stay writable while relocating.
3. Code analysis has to stay inside the code extent and out of PT_INTERP. The CFG followed pointers into the /libexec/ld-elf.so.1 string at the start of text.
4. sceVideoOutSetBufferAttribute and sceVideoOutRegisterBuffers (PS4 names) are absent. They map onto the ...2 functions with pixel format ((f & 0xFFFF0000) << 32) | ((f & 0xFFFF) << 16), so 0x80000000 becomes 0x8000000000000000.
5. __error: the sample imports it from libkernel, but AnyPS5 exports it from libc.prx. libc.prx is only added when libSceLibcInternal.prx is needed; PS5 games always need it, this sample doesn't.
6. param.json: AnyPS5 requires it, but PS4 titles ship param.sfo. I used a minimal param.json.
7. Display buffer alignment: the second linear buffer starts 8,294,400 bytes in, so it is only 4 KiB aligned. AnyPS5 requires 64 KiB.
8. sceVideoOutGetFlipStatus (see below).
9. _readv, _writev, _fcntl, _ioctl: thin wrappers over existing functions.

Side finding: APS5_DUMP_FRAMES writes nothing for linear display buffers. VulkanDevice::PresentDisplayBuffer returns from the linear path before the dump code, so this also affects PS5 titles.

On the two statements in #159

"the PS5's system libraries have everything needed"

The console may well ship everything. AnyPS5, though, reimplements the libraries PS5 games use, and PS4 games also need some outside that set. Bloodborne has 701 imports, and 233 of them come from the game's own bundled libc.prx and libSceFios2.prx. That leaves 468 system imports:

• 308 implemented;
• 8 stubs;
• 152 absent:
  • 50 libSceGnmDriver;
  • 91 online (Np);
  • 6 SaveData;
  • 3 Ajm;
  • 2 VideoOut, the PS4-only names from item 4.

"no problems with versioning system libraries"

There is one data point for PS4 callers. sceVideoOutGetFlipStatus has the same NID on both consoles, but:

• the PS4 SceVideoOutFlipStatus is 0x40 bytes;
• AnyPS5 writes the PS5 one, 0x80 bytes.

The first 0x40 bytes have the same layout (flipArg at 0x18). The other 0x40 bytes landed on the saved rbp of the sample's flip-wait function, and it crashed right after the first flip. Writing 0x40 bytes fixed it. So PS4 support needs a way to tell PS4 callers apart, for example PT_SCE_DYNLIBDATA in the executable or its SDK version. I don't know how the PS5's own library does it.

What PS4 games would need

1. Relinker (small to medium):
   • the two ready fixes;
   • items 1–3 above;
   • inline jump tables (Bloodborne's current stop).
2. Loader (small): items 5 and 6.
3. Libraries (small to medium):
   • PS4 names and PS4 struct sizes, with a way to detect PS4 callers;
   • items 4 and 7–9;
   • Np that reports offline;
   • the SaveData and Ajm gaps.
4. Graphics (large): libSceGnmDriver and the PS4 GPU path behind it. PS4 shaders are GCN code, while AnyPS5's shader recompiler targets the PS5's RDNA 2 instructions. The two are related but not encoded the same way, so this needs a GCN front end or a separate path. I haven't measured how much of the existing recompiler could be reused. shadPS4 implements this layer for its PS4 emulator and could serve as a reference.

Items 1–3 are enough for CPU-drawn homebrew. Retail games need item 4, which is a decision for the maintainers.

I can share the dumped frames and the experimental changes if that helps.

AI-assisted: yes (Claude Code). I ran every result above locally.

🤖 Generated with Claude Code