RetroArchV for PlayStation 4

Install

Install the package like every port here: copy it to the console and use the Package Installer, then launch RetroArchV.

It installs under its own title id, RTRV00001, so it sits beside any RetroArch already on the console rather than replacing it — the system decides collisions by title id, not by the name on screen.

First run

Online Updater → Update Core Info Files. Do this before browsing the core list. Core metadata is not shipped inside the package, so until those files arrive the downloader lists .prx filenames instead of names like “Nintendo 64 (Mupen64Plus-Next)”. Everything works either way; only the labels are missing.

With a console that has no network

Download the archive above on another machine, unzip it, and copy the .prx files into /data/retroarch/cores over FTP. Nothing else is needed — the core list is read from that directory at startup.

Core metadata works the same way offline: the .info files live in /data/retroarch/info and can be copied across from libretro's bundle.

Where everything lives

All of it sits under /data/retroarch/, which is writable and survives reinstalling the package. Put files there over FTP and RetroArch finds them at startup — there is no import step.

The package itself is mounted read-only at /app0 and holds only the executable, the icon and the certificate bundle. Nothing there needs editing, and nothing there can be.

Configuring it

Once the cores are in place, this is ordinary RetroArch. Controller mapping, shaders, overlays, per-core options, save states, rewind, netplay's absence, the scanner, playlists — all of it behaves as it does everywhere else, with the same menus in the same places. The libretro documentation applies unchanged, and so does any guide written for another platform.

Two habits worth having early: Load Content scans a directory for anything a core claims, and per-core settings live under Quick Menu → Options while the game is running, saved with Manage Core Options.

Source code and licences

RetroArch is licensed under the GNU General Public License, version 3, and most cores here are GPL of one vintage or another. Distributing these binaries obliges us to hand you the source they were built from — not the project in general, but the exact commit. That is what the last column of the table below is: each core's version links to the tree it was compiled from, and a core built with patches of this port's own also links those patches.

The frontend and the platform work:

• orbis-ports/RetroArch at v0.1.8 — the frontend, GPLv3, forked from libretro/RetroArch
• orbis-ports/mesa-ps4 — Mesa with a PlayStation 4 winsys and video-out layer (MIT)
• orbis-ports/orbis-compat — the platform overlay: libc and pthread corrections, packaging, logging
• orbis-ports/beetle-psx-libretro — the PlayStation core, forked for this platform
• orbis-ports/3dsTrident — the Nintendo 3DS core, forked for this platform
• BearSSL (MIT) for TLS, and the OpenOrbis toolchain

Known limits

• Closing the application from the console's own menu still shows CE-34878-0. It is cosmetic — the console recovers on its own. Quit from inside RetroArch does not.
• 68 of the 182 cores in the build recipe do not build for this platform yet. The ones listed here are the ones that link and export a working entry point.
• Cores are built from upstream's tip on the day the build ran, so a core's version is a date rather than a release number.

Most cores run well on their defaults. These are the exceptions: options whose default was chosen for a desktop computer and is wrong on this console, or that a game here was found to need. Change them under Quick Menu → Options while a game is running, and keep them with Manage Core Options → Save Core Options.

Every file the console's own Core Downloader offers, and where each came from.

37 of the 114 have been run on a real PlayStation 4, and the On a PS4 column says what happened. Everything else has only been built: it compiles, links and loads as a module, and nobody has yet written down what it does with a game. A report either way is useful.

• Plays a game runs and is playable
• Slow runs, below full speed
• Boots loads and responds; no game recorded yet
• Broken loads, then fails
• untested built, never run on a console

A result describes the build that was on the console that day. Cores are rebuilt from upstream on every run, so the file here can be newer than the one that was tested.