Inside fpPS4: Pascal units, a Vulkan path, and a core rewrite in flight

Pascal units at the root, and directories named after the machine parts

fpPS4 sets out to be a PS4 compatibility layer written with Free Pascal, and the repository layout describes the plan before any prose does. The guest-side handling is split across separate units at the top level rather than gathered into one large source file, and the machine-side work is sorted into directories.

fpPS4.lpr
fpPS4.lpi
fpPS4.res
ps4_elf.pas
ps4_program.pas
ps4libdoc.pas
tag.inc
as_only.cmd
as_shader_dump.cmd

`ps4_elf.pas` covers the executable side of a guest image, `ps4_program.pas` covers the program side, and `ps4libdoc.pas` covers the library surface that a title links against. That last name reads as a description of the imported surface rather than its implementation, which fits a core that is still being rewritten. `tag.inc` is the kind of file that carries a build stamp.

Everything else is filed by machine part:

chip/
kernel/
rtl/
sys/
static/
vulkan/
spirv/
shaders/
ffmpeg/
tools/
third_party_gui/

Written this way the layering is legible: parse the executable, build a program image, resolve what the title imports, then hand the result to a backend that speaks Vulkan. Pascal is an unusual language for that last step, and the directory split is what lets one person carry all of it without a large team.

The kern branch rewrite against the kernel/ directory on trunk

Two objects in this project differ by one letter and get confused easily. The README says the emulator core is being rewritten in the `kern` branch, and that until that work finishes there will be no support for specific games. The default branch is `trunk`, and `trunk` carries a directory named `kernel/`. One is a branch that will hold a future core, the other is kernel-side code that exists today.

A clone of `trunk` gives you neither view of the rewrite, nor any marker telling you which core you have. A build from `trunk` today runs a compatibility layer its own author has already declared mid-rewrite.

Version numbers sharpen the gap. The last push on the default branch was on 2026-09-27, while the newest tag `v0.0.1` carries the date 2022-12-31 and the two before it, `draft29062022` and `draft30062022`, are dated in June 2022. Installing from a versioned build therefore hands you a tree that predates nearly four years of commits, and the two draft names read as sequencing markers rather than as anything a user can evaluate.

Two pinned toolchains and no build command at all

Building is documented as a pair of version numbers and stops there. There is no configure step, no dependency file and no container recipe in the top-level tree, and the README gives no command line that produces an executable.

Free Pascal compiler: 3.3.1 (use fpcupdeluxe with trunk), x86_64 only.
Lazarus: 2.0.0 and higher, x86_64 only.

`fpcupdeluxe` is named as the installer, with its `trunk` channel selected, which is how the pinned 3.3.1 compiler is obtained. Lazarus is named separately because `fpPS4.lpi` is a Lazarus project file, so the IDE version decides whether the saved project opens. Both entries are marked x86_64 only, which narrows the question before any library question arises.

The rest of a first build is guesswork, and the tree offers two hints. `as_only.cmd` and `as_shader_dump.cmd` are Windows batch wrappers sitting at the top level beside `tools/`, so part of the pipeline expects a cmd shell rather than a POSIX one. Nothing in the README explains what either wrapper invokes, what output a successful run produces, or what to do when compilation stops at the first unimplemented routine.

Windows, AVX2 and Vulkan are floors rather than targets

Three minimum requirements sit under their own heading, and each one closes a door rather than recommending a setting.

OS: Windows 7 SP1 x64 and higher
CPU: x64, AVX2 support
GPU: Vulkan API support

AVX2 on an x64 CPU is a vector-instruction floor, which matches a tree whose CPU-side work lives in `chip/`. Vulkan support on the GPU side matches `vulkan/`, `spirv/` and `shaders/` sitting together, with the spirv directory holding the compiled shader forms the backend consumes. Windows is the only operating system named, and the floor is Windows 7 SP1, so a plan to build or run this on Linux or macOS has no documented path here.

Read as a set, the three lines describe a host that is old enough to predate current driver defaults, paired with an emulator that needs every host capability lined up before it spends any effort on the guest. Nothing in the README says which of the three is checked at start-up and which failure only appears later, inside a running title.

Twenty-three keys cover the pad except SHARE, TOUCHPAD and PS

Input runs along three paths, and the keyboard table is the part worth counting. Alt-Enter switches to borderless full screen, Esc on the keyboard during emulation opens button remapping, XInput-compatible pads are supported natively, and the mouse stands in for a DualShock4 touchpad.

PS4 Gamepad button | Keyboard button
:------------ | :------------
Left Stick Up |W
Left Stick Left |A
Left Stick Down |S
Left Stick Right |D
Right Stick Up |I
Right Stick Left |J
Right Stick Down |K
Right Stick Right |L
OPTIONS |Enter

Dpad Up |Arrow Up
Dpad Left |Arrow Left
Dpad Down |Arrow Down
Dpad Right |Arrow Right
Triangle |Numpad 8
Square |Numpad 4
Cross |Numpad 2
Circle |Numpad 6
L1 |Q
L2 |1
L3 |Z
R1 |E
R2 |4
R3 |C

Twenty-three rows, and three PS4 controls have no entry at all: SHARE, the touchpad click and the PS button. A player who wants those stays on an XInput pad, and the touchpad surface itself is reachable only through the mouse. Esc is spoken for as well, because it is the remap trigger while a title runs, so a game binding Esc to an action will not receive it. OPTIONS sits on Enter alone, which means the Alt-Enter window toggle also delivers an OPTIONS press to whatever is running.

Per-title answers live in a tracker owned by another repository

Support data is kept outside this repository. The compatibility list is an issue tracker in `fpps4-game-compatibility`, linked twice from the README, and the README tells readers that a game which fails should be checked there first rather than reported in the code repository: "If your game doesn't work don't create a new issue, check the compatibility list first."

That arrangement has a cost. Nothing in this repository records which titles run, so coverage cannot be judged from the source tree, and a reader gets a link instead of a table. It also means no file here accumulates failures for the project's own history, which makes regressions hard to notice when they happen on a branch nobody follows closely.

The tracker being an issue list rather than a generated report is the other detail worth sitting with. Its accuracy depends on whoever tested a title filing what they saw, and the README's own instruction is aimed at people who already know the answer, at the cost of the person who does not.

What the README leaves out: loading, saves, crashes and rollback

The project is candid about its ceiling and quiet about its floor. The README calls the emulator still in the early stages of development, says big games do not work, and says the work started for fun. What it does not document is how a game image is loaded, whether any save data is read or written, what a title does when it calls a routine the core has not implemented, how to roll back a change that breaks a title that worked, or what frame time looks like on any machine.

The alternative sits inside the project rather than beside it. Growing coverage title by title against a hand-kept list is what the current tree does. Rebuilding the core underneath games on `kern` is what the author says is happening instead, and while that rewrite runs there is no support for specific games at all. Neither path carries a schedule, so the only thing available to compare is the switch itself, and the README says nothing about what replaces the tracker while the rewrite is in flight.

Before building anything on top, read the licence text in `LICENSE` and check what LGPL-2.1 asks of a binary you distribute, since the README is silent on relicensing and on exceptions.

Editorial conclusion

fpPS4 is worth reading for anyone who wants to build a console compatibility layer from the outside in, and it is the wrong tool for anyone hoping to run a retail title this weekend. The README states that big games do not work and that specific game support is suspended until the core rewrite on the kern branch is done. Before building, verify the two pinned toolchains against your own host, then check the per-title record in the fpps4-game-compatibility tracker, since neither the build recipe nor the coverage table lives in this repository.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-2.1
3. README
4. red-prig/fpPS4 on GitHub
5. Releases