Releases

RiptOPL ships on two channels: a continuously-rebuilt rolling pre-release (every master push) and curated v* tagged releases. Both are produced by the same pipeline and carry the same asset set, so they can never silently diverge.

ℹ 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>-PS2DEVLATESTSDK-ds5.ELF (and the matching -PS2DEVPINNEDSDK-ds5.ELF). make DUALSENSE=1 is only needed if you compile your own. A second, experimental extra — a forced-1080p GSM video mode — ships only as RIPTOPL-PS2DEVLATESTSDK-1080p.ELF (published without a version in the filename, unlike the rest; latest-SDK flavour only, gated behind a three-step in-GUI confirmation; the raster is hardware-unvalidated). Every other asset is 1080p-free.

Release channels

Channel	Tag	When to use	Stability
Rolling pre-release	`rolling`	Latest features, actively tested builds, eager testers	Development builds — may be unstable
Tagged release	`v*` (e.g. `v1.2.0`)	Stability-first installs, setups you do not want to touch often	Curated, known-good

Release notes on the rolling channel show the source commit, build version, build timestamp, and the CI run that produced it. Release candidates use an -rc* suffix and stay as pre-releases; a bare v* tag produces a full (non-pre-release) release.

What the rolling release contains

Every push to master wipes the previous rolling assets and republishes a fresh set. The headline item is a full installable package zip; all other assets are published alongside it.

Asset	What it is
`RIPTOPL-<rel>-<sha>.zip`	The installable package. Contains labeled SDK loader folders: `APP_RIPTOPL-PS2DEVLATESTSDK/RIPTOPL.ELF` (#1, built with the current `ps2dev/ps2dev:latest` SDK), and `APP_RIPTOPL-PS2DEVPINNEDSDK/RIPTOPL.ELF` (#2, built on a digest-pinned ps2dev SDK as the safe fallback), the `POPSTARTER/` and `POPS/` folders for PS1 support, the bundled `neutrino/` folder, and a `PS2-Servers.url` shortcut. Extract it and use `APP_RIPTOPL-PS2DEVLATESTSDK/RIPTOPL.ELF`.
`RIPTOPL-<version>-PS2DEVLATESTSDK.ELF`	Bare loader ELF, `ps2dev/ps2dev:latest` toolchain (#1 recommended).
`RIPTOPL-<version>-PS2DEVPINNEDSDK.ELF`	Bare loader ELF, digest-pinned `ps2dev/ps2dev` toolchain (#2 safe fallback).
`RIPTOPL-<version>-<SDK>-ds5.ELF`	DualSense (DS5 USB) pad support loader ELFs for each SDK toolchain flavour (`DUALSENSE=1`).
`RIPTOPL-<version>-src.zip`	Source snapshot of the exact built commit — you can rebuild this precise revision later.
`SHA256SUMS.txt`	SHA256 checksums for every published binary and the source snapshot.
`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-VARIANTS-*.zip`	Alternate build configs and variants for testing or diagnostics.
`RIPTOPL-DEBUG-*.zip`	Debug builds (`iopcore`, `ingame`, `eesio`, `iopcore_ppctty`, `ingame_ppctty`, `DTL_T10000` variants). For diagnostics only.

<version> is the build's git describe output, e.g. v1.2.0-Beta-2559-bb25a00 — one authoritative version, taken from the recommended ps2dev:latest build and applied to both flavours. <sha> is the first 16 hex characters of the recommended ELF's SHA256 — a uniqueness tag, not a security guarantee. The full checksums are in SHA256SUMS.txt.

Two toolchains, one recommended

Every build runs under two PS2 toolchains simultaneously:

ps2dev/ps2dev:latest — the current SDK, and the build RiptOPL is developed and tested against. This is the recommended ELF, in APP_RIPTOPL-PS2DEVLATESTSDK/RIPTOPL.ELF. Because it tracks a moving tag it can occasionally regress on hardware (issue #102), which is what the pinned flavour is for.
ps2dev/ps2dev@sha256 (digest pin) — the same ps2dev SDK, pinned to a day it was known good. Its output goes into APP_RIPTOPL-PS2DEVPINNEDSDK/RIPTOPL.ELF. Use it if the recommended build black-screens or the cursor is dead on your console.

The recommended ps2dev:latest build must compile — if it fails, the publish fails loudly rather than shipping a partial release. The digest-pinned fallback is best-effort: if it fails, the release still updates without it and the notes say so. The SHA256SUMS.txt covers whichever ELFs were actually produced.

Bundled Neutrino core

The installable package ships the latest official rickgaiser/neutrino pre-release 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 to mc?:/neutrino/ (neutrino.elf plus the config/ and modules/ folders are already inside). 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

# The zips only: the installable package plus the src / LANGS / VARIANTS / DEBUG extras
# (the version string itself contains dashes, so this glob matches all of them)
gh release download rolling --repo NathanNeurotic/Open-PS2-Loader \
  --pattern 'RIPTOPL-*-*-*.zip' --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 master → updates the rolling pre-release (the development channel).
Push of a v* tag → cuts a curated per-version release for that tag, publishing the identical asset set. An -rc* tag stays a pre-release; a bare v* tag makes a full release.
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 master push and a simultaneous v* tag release run in separate concurrency groups and do not cancel each other.

Why are there two toolchain builds in the same release?

The PS2 toolchain (ps2dev/ps2dev:latest) is a moving tag: it advances continuously and occasionally introduces regressions (issue #102). The same commit is therefore also built against a digest pin of that SDK, so you can fall back instantly without waiting for a fix commit: if a game stops booting, use APP_RIPTOPL-PS2DEVPINNEDSDK/RIPTOPL.ELF instead of APP_RIPTOPL-PS2DEVLATESTSDK/RIPTOPL.ELF on your memory card or USB drive and retry. Report which flavour reproduced it so the regression gets fixed for everyone.

When should I use the VARIANTS or DEBUG zips?

VARIANTS cover the full cross-product of EXTRA_FEATURES (on/off) × PADEMU (on/off) × DUALSENSE (on/off) in both SDK flavours — useful if you want to isolate a compatibility difference introduced by one of those build flags. DEBUG builds (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-<rel>-<sha>.zip. The contents are ready to copy to your memory card or USB drive root:

APP_RIPTOPL-PS2DEVLATESTSDK/
  RIPTOPL.ELF          ← use this (ps2dev:latest, recommended)
APP_RIPTOPL-PS2DEVPINNEDSDK/
  RIPTOPL.ELF          ← digest-pinned fallback if the recommended build misbehaves
POPSTARTER/            ← SMB network stack + bdma_config.txt
POPS/                  ← POPSTARTER.ELF and BDMA variants
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-PS2DEVLATESTSDK/RIPTOPL.ELF to wherever your launch method (FMCB, FHDB, or equivalent) expects it. The shipped folders carry an SDK-flavour suffix so the two builds 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 — just copy the whole folder (neutrino.elf plus the config/ and modules/ folders) to mc?:/neutrino/. 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 standard ELF has the fork-specific UI strings machine-translated into all 31 bundled languages, but rarer scripts may need the external font.

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