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. The one optional extra is DualSense / DualShock 5 (USB) support, which must be compiled in with make DUALSENSE=1 and is not part of the standard release ELF.

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-<sdk>-<rel>-<sha>.zip`	The installable package. Contains `APP_RIPTOPL/RIPTOPL.ELF` (built with `ps2dev/ps2dev:latest`, the default), `APP_RIPTOPL-OLDSDK/RIPTOPL.ELF` (the pinned/stable toolchain, as a fallback), the `POPSTARTER/` and `POPS/` folders for PS1 support, and the bundled Neutrino core archive (`neutrino_*.7z` — with `config/bsd-udpfsbd.toml` injected so UDPFS works on extraction). Extract it and use `APP_RIPTOPL/RIPTOPL.ELF`.
`RIPTOPL-<version>.ELF`	Bare loader ELF, `ps2max/dev` pinned toolchain.
`RIPTOPL-<version>-ps2dev-latest.ELF`	Bare loader ELF, `ps2dev/ps2dev:latest` bleeding-edge toolchain.
`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: the full `EXTRA_FEATURES × PADEMU` matrix, in both SDK flavours. For testing or diagnostics.
`RIPTOPL-DEBUG-*.zip`	Debug builds (`iopcore`, `ingame`, `eesio`, `iopcore_ppctty`, `ingame_ppctty`, `DTL_T10000` variants), both SDK flavours. For diagnostics only.

<version> is the pinned build's git describe output, e.g. v1.2.0-Beta-2559-bb25a00. <sdk> is the pinned SDK tag (e.g. v20250725-2). <sha> is the first 16 hex characters of the default ELF's SHA256 — a uniqueness tag, not a security guarantee. The full checksums are in SHA256SUMS.txt.

Two toolchains, one default

Every build runs under two PS2 toolchains simultaneously:

ps2dev/ps2dev:latest — the bleeding-edge toolchain. This is the default ELF inside APP_RIPTOPL/RIPTOPL.ELF. It tracks PS2SDK closely and usually produces the best binary.
ps2max/dev (pinned) — a specific, locked toolchain version. Its output goes into APP_RIPTOPL-OLDSDK/RIPTOPL.ELF. Use this if the default ELF has a regression on your console.

The bleeding-edge build is best-effort: if it fails, the rolling release still updates with the pinned build, and the release notes flag that the bleeding-edge binary is absent that run. The SHA256SUMS.txt covers whichever ELFs were actually produced.

Bundled Neutrino core

The installable package ships the latest official rickgaiser/neutrino pre-release as neutrino_*.7z at the package root. RiptOPL adds only one file into that archive — config/bsd-udpfsbd.toml — so UDPFS works on extraction without a manual copy step. Everything else is the official Neutrino build, unchanged.

ℹ After extracting

Extract neutrino_*.7z and copy neutrino.elf (plus the config/ and modules/ folders) to mc?:/neutrino/. 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

# Just the installable package zip
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) advances continuously and occasionally introduces regressions. Shipping both the bleeding-edge and a pinned build lets you fall back instantly without waiting for a fix commit: if a game stops booting, copy APP_RIPTOPL-OLDSDK/RIPTOPL.ELF over APP_RIPTOPL/RIPTOPL.ELF on your memory card or USB drive and retry. Report the regression upstream so it 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) 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-<sdk>-<rel>-<sha>.zip. The contents are ready to copy to your memory card or USB drive root:

APP_RIPTOPL/
  RIPTOPL.ELF          ← use this (ps2dev:latest, default)
APP_RIPTOPL-OLDSDK/
  RIPTOPL.ELF          ← fallback if the default has a regression
POPSTARTER/            ← SMB network stack + bdma_config.txt
POPS/                  ← POPSTARTER.ELF and BDMA variants
neutrino_*.7z          ← official Neutrino core (extract separately)

Install the ELF via your launch method

Copy APP_RIPTOPL/RIPTOPL.ELF to wherever your launch method (FMCB, FHDB, or equivalent) expects it. The folder name APP_RIPTOPL is the OPL convention for homebrew apps stored on your device.

Set up Neutrino (optional)

Extract neutrino_*.7z and copy 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.