External Tools & Services

PS2-Servers by Ripto — all-in-one PC server launcher for SMB, UDPFS, UDPBD and HTTP.
udpfs-server by YouKnow-sys — the same idea from a phone: an Android app that shares folders and disk images to the PS2 over UDPFS, found by broadcast so there is no server address to type in on the console. Built on udpfsd by pcm720; MIT licensed.
OrbitPS2 Manager by Luden — cross-platform PC library manager for importing discs, artwork/screenshots, ZSO compression, per-game settings and VMC management.
OPL PS1 AIO Converter GUI by shaan — Windows all-in-one PS1/POPStarter preparation tool for BIN/CUE → VCD conversion and installation to USB, MX4SIO, MMCE, iLink, exFAT HDD, SMB and APA internal HDD.
xeRAbora by hacan359 — the PC client for RetroAchievements on real PS2 hardware. Required client: v0.1.0-alpha.10. RiptOPL's RA build is paired with and requires xeRAbora v0.1.0-alpha.10. xeRAbora runs rcheevos, talks to the RetroAchievements servers, unlocks achievements and builds the per-game watch list. Shipped as a shortcut inside RIPTOPL-RetroAchievements-*.zip; MIT licensed. RiptOPL’s RA stabilization on real hardware was driven by oMrRexD, whose PRs #702–#705 fixed the ee_core stack squeeze, MMCE DEV9 path, cold-launch networking and settings placement.
OPL HTTP PC server by Docmine17 — the PC side of RiptOPL’s HTTP protocol: a small static HTTP server with byte-range support that serves your games.csv catalog and streams the ISOs. RiptOPL works with it unmodified — no new API, no catalog conversion, no changed layout — with host conformance checks against the upstream server; PS2 hardware validation is still pending.
PS2RD CHT Manager by TheRealNextria — PC manager for the PS2RD .cht cheat files RiptOPL reads from your device's CHT folder.
Ember by Gageformer — a PS1 emulator running natively on the PS2, used as RiptOPL's second PS1 core alongside POPSTARTER. Ships as an EMBER/ folder inside the release package, bundled unmodified under the Ember Public Beta Testing Licence (EMBER/LICENSE-BETA.txt); releases.
POPStarter by krHACKen — a PS1 launcher built around Sony's native POPS emulator for the PS2, used as RiptOPL's primary PS1 core alongside Ember. POPStarter provides the compatibility and launch layer for running PS1 VCDs from USB, MX4SIO, MMCE, iLink, internal HDD, and SMB; RiptOPL's iLink handoff is wired but still awaiting a passing hardware retest. The official POPStarter r13 package contains no Sony emulator binaries, libraries, or BIOS files; those components must be supplied separately by the user. Official download, documentation, compatibility information, and releases are maintained on PSX-Place.
Neutrino by rickgaiser — a small, fast, modular PS2 device emulator, and RiptOPL's second PS2 loader core alongside OPL's own. Ships as a ready-to-use neutrino/ folder inside each installable ZIP (drag-and-drop to mc?:/neutrino/), under the AFL-3.0 licence; releases.
PSUManager by techwritescode — the CC0 PS2 save-container implementation used by RiptOPL release tooling to independently validate APP_RIPTOPL.psu and APP_RIPTOPL-RA.psu. The exact upstream core and license used by CI are preserved in third_party/PSUManager/.

Releases

Choose Rolling for current development or Current Fan Favorite Build for a preserved development snapshot. The publishing branch is rebuild/main; neither choice guarantees compatibility with every setup.

ℹ One full-feature build

RiptOPL ships a single standard ELF that includes GSM video-mode handling, DS3/DS4 pad emulation (PADEMU), VMC (Virtual Memory Cards), PS2RD cheats, and parental controls. There are no stripped-down per-feature variants to juggle. One optional extra is DualSense / DualShock 5 (USB) support: it is off in the standard ELF, but you do not have to build it yourself — the rolling release publishes a ready-made RIPTOPL-<version>-<SDK>-ds5.ELF for each available SDK flavour inside RIPTOPL-VARIANTS-*.zip. make DUALSENSE=1 is only needed if you compile your own. Forced-progressive 1080p GSM support is hardware-confirmed and built into every standard loader. Selecting it is guarded by a three-step in-GUI confirmation, and holding Triangle + Cross during console boot forces 480p for the OPL menu only; the display and connection must accept it.

Release channels

Channel	Tag	When to use	Stability
Rolling (Latest)	`rolling`	Latest features, actively tested builds, eager testers	Development builds — may be unstable
Current Fan Favorite Build	`current-fan-favorite`	A fixed development snapshot for comparison	Selected after positive feedback; compatibility varies

Release notes on the rolling channel show the source commit, build version, build timestamp, and the CI run that produced it. The rolling channel is a full (non-pre-release) development release and intentionally owns GitHub's Latest marker. Release candidates use an -rc* suffix and stay as pre-releases; a bare v* tag produces a full curated release without displacing rolling.

What the rolling release contains

Successful publishing runs on rebuild/main replace the rolling assets. Archives are organized by purpose: the normal installable package, RA development package, exact source, VARIANTS, and optional language/debug packs. Read the release notes for omitted flavours or companion downloads.

Asset	What it is
`RIPTOPL-<version>.zip`	The installable package. Normally contains four explicitly labelled SDK loader folders (a best-effort flavour can be absent when its build fails, and the release notes identify it): `APP_RIPTOPL-PS2DEVPINNED/` (#1, recommended pinned ps2dev), `APP_RIPTOPL-OFFICIALPINNED/` (#2, recommended official pin), `APP_RIPTOPL-PS2DEVROLLING/` (#3, moving ps2dev canary), and `APP_RIPTOPL-OFFICIALROLLING/` (#4, moving official canary), one canonical `POPS/` folder for POPSTARTER support (every BDMA pair stays loose there, including `usbd.irx.ilink` + `usbhdfsd.irx.ilink`; none is embedded), the bundled `EMBER/` and `neutrino/` folders, and five companion-tool shortcuts. Start with `APP_RIPTOPL-PS2DEVPINNED/RIPTOPL.ELF` when that best-effort flavour is present. The presence of the loose iLink pair documents package contents, not a hardware pass: revision 2692's POPSTARTER iLink launch still returned to wLaunchELF in every flavour.
`RIPTOPL.ELF`	The loader on its own, for updating an install you already have. Download it and overwrite your existing `RIPTOPL.ELF` — no archive to unpack, nothing else to copy. Alone among the release assets its name never changes, so the download link is permanent. It is the `-OFFICIALROLLING` flavour, and there is only one of these on purpose: four would put the "which do I pick?" question back in front of the people this asset exists for. Not a first install — the bare loader does not bring `POPS/`, `EMBER/`, `neutrino/` or the language files, so PS1 and Neutrino launches still need the package above. For a reproducible build to quote in a bug report, take a pinned folder from the package instead. Best-effort, like the flavour it is copied from: if that build fails the release ships without it.
`RIPTOPL-<version>-src.zip`	Source snapshot of the exact built commit — you can rebuild this precise revision later.
`RIPTOPL-LANGS-*.zip`	Extra UI language files (`.lng` files and non-Latin fonts not embedded in the ELF). Copy into your OPL folder alongside the ELF.
`RIPTOPL-RetroAchievements-*.zip`	RetroAchievements build, as a complete package: the same `POPS/`, `EMBER/`, `neutrino/` and PC-tool shortcuts as the main archive, with `APP_RIPTOPL-RA-PINNED/` and `APP_RIPTOPL-RA-ROLLING/` loader folders (and a `-nopademu` build of each) in place of the standard ones, plus `xeRAbora.url` for the PC client the feature talks to. Take this one instead of the main archive if you want achievements. A development build: it is written end to end but has not been tested on real hardware yet. See docs/RETROACHIEVEMENTS.md.
`RIPTOPL-VARIANTS-*.zip`	The full `EXTRA_FEATURES` × `PADEMU` × `DUALSENSE` matrix for the two ps2dev flavours, plus one ready-made DualSense (`DUALSENSE=1`) loader for each available official flavour.
`RIPTOPL-DEBUG-*.zip`	Debug builds for the two ps2dev flavours (`iopcore`, `ingame`, `eesio`, `iopcore_ppctty`, `ingame_ppctty`, and `DTL_T10000`). For diagnostics only.

<version> in a download's name is the build version without its commit, e.g. v1.2.0-Beta-2915 — one authoritative version, taken from the required ps2dev:latest build and applied to all four flavours. The full version, commit included (for example v1.2.0-Beta-2915-da28622), is in the release notes header and on the loader's About screen.

ℹ One loose ELF, everything else in archives

The normalizer keeps exactly one floating loader, the stable-named RIPTOPL.ELF update download, and deliberately removes every other floating ELF, checksum list, detailed changelog, and SDK/IRX manifest from the GitHub asset list. The other standard loaders are inside the unified package; DualSense loaders are inside RIPTOPL-VARIANTS-*.zip.

Four toolchain flavours, ordered for testing

Every release attempts four labelled flavours of the same RiptOPL source, in this recommended order:

APP_RIPTOPL-PS2DEVPINNED/ — digest-pinned ps2dev; recommended primary control.
APP_RIPTOPL-OFFICIALPINNED/ — digest-pinned official ps2homebrew toolchain.
APP_RIPTOPL-PS2DEVROLLING/ — moving ps2dev:latest canary.
APP_RIPTOPL-OFFICIALROLLING/ — moving official ps2homebrew:main canary.

The PS2DEVROLLING canary must compile — if it fails, the publish fails loudly rather than shipping without its required build. The other three flavours are best-effort: if one fails, the release still updates without that folder and the notes identify the omission.

Bundled Neutrino core

The installable package ships the latest published official rickgaiser/neutrino build as an already-extracted neutrino/ folder at the package root (holding neutrino.elf plus the config/ and modules/ folders) — no zip-in-zip, so you just drag-and-drop it. RiptOPL adds only one file — config/bsd-udpfsbd.toml — so UDPFS works out of the box without a manual copy step. Everything else is the official Neutrino build, unchanged.

ℹ Copying it over

There is nothing to extract: copy the whole neutrino/ folder, including neutrino.elf, config/ and modules/. For ordinary non-MMCE setups, mc0:/neutrino/ or mc1:/neutrino/ is supported. For MMCE games with GameID card switching, place it on the MMCE game device instead — normally mmceN:/neutrino/, or under the configured MMCE Prefix Path. An mcN:-hosted Neutrino would conflict with that slot's card switch, so RiptOPL protects the handoff by skipping the switch; an mmceN: copy is unaffected. Auto probes the active game device before memory-card fallbacks. See Neutrino Core for the full setup guide.

How to pull the rolling release

Because filenames embed the version and short SHA, they change on every push. Pull by the rolling tag rather than a fixed filename so you always get what is currently published:

# Everything in the current rolling release
gh release download rolling --repo NathanNeurotic/Open-PS2-Loader --clobber

Or download directly from the release page:
github.com/NathanNeurotic/Open-PS2-Loader/releases/tag/rolling

ℹ No stale accumulation

Every prior run's assets are deleted before the new set is uploaded, so old builds do not pile up on the release page. GitHub's automatic "Source code" archives (added separately by GitHub) are the only exception.

How the pipeline works

One workflow file — .github/workflows/rolling-release.yml — is the single place release packaging lives. The pushed ref picks the publish target:

Push to rebuild/main or master → updates the rolling full development release, explicitly clears its pre-release flag, and keeps it marked as GitHub Latest.
Push of a v* tag → cuts a curated per-version release for that tag, using the same normalized package format and best-effort rules. An -rc* tag stays a pre-release; a bare v* tag makes a full release. Neither displaces rolling from the Latest marker.
Manual workflow_dispatch → re-runs as rolling.

A concurrency group cancels in-flight rolling runs when a newer push arrives, so the release always reflects the freshest commit. A publishing-branch push and a simultaneous v* tag release run in separate concurrency groups and do not cancel each other.

Why are there four toolchain flavours in the same release?

The moving ps2dev and official toolchain tags can advance independently and occasionally introduce regressions. Each lineage therefore has a digest-pinned control beside its moving canary. Start with APP_RIPTOPL-PS2DEVPINNED/RIPTOPL.ELF; if hardware behavior differs, test the other labelled folders and report the exact in-app flavour suffix so application and SDK regressions can be separated.

When should I use the VARIANTS or DEBUG zips?

VARIANTS contain the full EXTRA_FEATURES × PADEMU × DUALSENSE matrix for the moving and pinned ps2dev flavours. The normalizer also adds a ready-made DualSense loader for each available official flavour; it does not build the complete official-toolchain matrix. DEBUG builds are produced for the two ps2dev flavours only. Those configurations (iopcore, ingame, eesio, iopcore_ppctty, ingame_ppctty, DTL_T10000) emit diagnostic output over a UART/TTY; they are only useful if you have the hardware or emulator setup to capture it. Do not use debug builds for normal gaming — they are significantly slower.

After downloading

Extract the package zip

Unzip RIPTOPL-<version>.zip. The contents are ready to copy to your memory card or USB drive root:

APP_RIPTOPL-PS2DEVPINNED/
  RIPTOPL.ELF          ← #1 recommended pinned control
APP_RIPTOPL-OFFICIALPINNED/
  RIPTOPL.ELF          ← #2 official pinned control
APP_RIPTOPL-PS2DEVROLLING/
  RIPTOPL.ELF          ← #3 moving ps2dev canary
APP_RIPTOPL-OFFICIALROLLING/
  RIPTOPL.ELF          ← #4 moving official canary
POPS/                  ← POPSTARTER.ELF and every loose BDMA variant (including .ilink)
EMBER/                 ← official Ember core; add your own BIOS and games
neutrino/              ← official Neutrino core (already extracted, drag-and-drop)
PS2-Servers.url        ← link to the UDPFS / SMBv1 / UDPBD all-in-one PC launcher

Install the ELF via your launch method

Copy APP_RIPTOPL-PS2DEVPINNED/RIPTOPL.ELF to wherever your launch method (FMCB, FHDB, or equivalent) expects it. If that best-effort folder is absent in a run, use the next available flavour in the order above. The labelled folders can sit side by side; the APP_ prefix is the OPL convention for homebrew apps stored on your device.

Set up Neutrino (optional)

The neutrino/ folder is already extracted — copy the whole folder (neutrino.elf plus config/ and modules/) to a resolver location. For ordinary non-MMCE setups, mc0:/neutrino/ or mc1:/neutrino/ is supported. For MMCE games using GameID card switching, use the active MMCE device instead (mmceN:/neutrino/, or under its Prefix Path). Required only if you want per-game Neutrino launching or network boot (UDPBD/UDPFS). See Neutrino Core.

Copy the language pack (optional)

If you want a non-default UI language, extract RIPTOPL-LANGS-*.zip and copy its .lng files and any non-Latin font files into your OPL/LNG/ folder. The pack covers 33 languages. RiptOPL's own strings are machine-translated in 31 of them; Galician and Serbian show those strings in English for now. Scripts the built-in font lacks need the font file from the pack too.

For a complete first-run walkthrough (folder layout, enabling devices, launching your first game), see Getting Started.

Archive availability

MEGA uploads require successful publishing and configured credentials. Superseded or failed runs may have no archive. Installable packages, source and metadata are archived when upload succeeds; VARIANTS and DEBUG are excluded. Neutrino download/extraction is best-effort, so check release notes before relying on a bundled core.

The rolling archive

Because the rolling release is rebuilt on every push, a build you were happy with is replaced quickly. Successful runs are preserved on MEGA under run-specific folders, so an older build can still be retrieved:

RiptOPL/Rolling/<version>/run_<number>/

Each folder holds the installable packages plus source and build metadata. VARIANTS and DEBUG bundles are excluded, and — as above — an upload only exists when that run published successfully and the credentials were configured, so superseded or failed runs may have no archive at all.

Browse the MEGA rolling archive →

Building from source

You do not need to build RiptOPL to use it — the releases above are ready to run. This is for people who want to change the code or produce a build with non-default options.

Build inside one of the toolchain images from the CI matrix. Both pinned and rolling SDK images work, and the latest SDK is not required. For a reproducible baseline use the PS2DEVPINNED image digest from that matrix. From the repository root, with Docker available:

docker run --rm -v "${PWD}:/src" -w /src   ps2dev/ps2dev@sha256:8fba50ecc2229acd7f8da63d34302f12939b7d4fa6848dda1e6a0ce083321a11   make -j4

Repository scripts live in tools/ and are run from the repository root. Existing Makefile targets keep their names and output locations.

⚠ Use a clean build directory when changing SDK image

Object files from one SDK are not safe to mix with another. Also worth saying plainly: a successful build does not establish console compatibility — it only means the code compiled.

See the Makefile for the option flags, including DUALSENSE=1 (a DualSense loader) and EXTRA_FEATURES=1 (which turns on in-game screenshots and right-to-left language support).