ps2build C++ migration

This repository is the C++/ps2build transition of RiptOPL. These guides include the production project's full documentation; feature and hardware parity are still being validated. The release targets are Korium, RetroAchievements and IncebtIon, all on ps2build. Check the migration ledger before treating an imported production feature as verified here.

Apps

RiptOPL can list and launch your homebrew ELFs alongside your games, on the Apps device page. There are two supported ways to register an app; both work, and you can use both at once.

Method	Use it when
`title.cfg` (folder-based)	You want each app self-contained inside its own folder under `APPS/`. This is the method to prefer for new setups.
`conf_apps.cfg` (legacy)	You want one central list, or your ELFs live somewhere other than `APPS/`.

RiptOPL is case-sensitive

Both methods match file names exactly, including letter case. MYAPP.ELF and myapp.elf are different files as far as the loader is concerned. This is the single most common reason an app does not appear or fails to launch.

The `title.cfg` method

One title.cfg per app folder. The ELF and its title.cfg must sit in the same folder under APPS/.

In APPS/, create a folder for the app.
Put the ELF in that folder.
Create a text file named title.cfg beside it.

APPS/
  MYAPP/
    MYAPP.ELF
    title.cfg

With title.cfg containing:

title=My App Name
boot=MYAPP.ELF

Using RiptOPL itself as an example:

title=Open PS2 Loader
boot=RIPTOPL.ELF

Keys

Key	Required	Meaning
`title`	Yes	The name shown in the app list.
`boot`	Yes	The ELF filename to launch, relative to the app's own folder.
`argv1`	No	A single argument passed to the ELF on launch, as its first argument. Useful for homebrew that takes a path or a mode on its command line.
`REBOOTIOP`	No	Answers the REBOOT IOP? launch prompt for this app once and for all: `YES` or `NO`. Has no effect when `conf_apps.cfg` also lists the ELF. See Launching an app.
`REBOOT_IOP`	No	Alias for `REBOOTIOP`. Values `1`/`0`, `YES`/`NO`, `TRUE`/`FALSE`, and `ON`/`OFF` are accepted.

argv1 and the per-app settings screen

argv1 shares storage with the per-app Custom ELF field ($AltStartup), so an argument set in title.cfg shows up there and can be edited from the console. When a folder-based entry and a legacy entry resolve to the same ELF, the folder-based one donates its argv1 to the legacy entry if that entry has none of its own.

The `conf_apps.cfg` method (legacy)

A single text file listing one app per line, in the form Display Name=DevicePathToELF:

Left of the = — the name shown in the app list.
Right of the = — the full device path to the ELF.

My App Name=mass:APPS/MYAPP.ELF
OPL=mass:APPS/RIPTOPL.ELF

Device prefixes:

Prefix	Device
`mass:`	USB, MX4SIO, iLink, exFAT HDD — any BDM device
`mmce0:` / `mmce1:`	MMCE (SD2PSX, MemCard PRO2)
`mc0:` / `mc1:`	Memory card
`hdd0:` / `pfs0:`	APA HDD

With this method the ELFs do not have to live in APPS/ — though keeping them there still makes a setup easier to manage.

Where RiptOPL looks for it

The search order is:

mc?:OPL/conf_apps.cfg — either memory card.
conf_apps.cfg under each enabled source's configured prefix.

The first file found wins — lists are not merged

If you have a conf_apps.cfg on the memory card and another on USB, only the memory card one is read. This trips people up when adding a second list and wondering why nothing changed.

With a default mass-device prefix, the file goes at mass0:/conf_apps.cfg. mass0:/OPL/conf_apps.cfg is only found when OPL/ is that source's configured prefix — it is not searched as an extra location.

Launching an app: the REBOOT IOP? prompt

Launching an ordinary app ELF, from Apps or from an app in Favorites, first asks REBOOT IOP?:

Button	Result
Cross (YES)	Reset the IOP before the app starts, so it begins with a freshly reset I/O processor.
Circle (NO)	Start the app on the IOP as RiptOPL left it, with its drivers still loaded.
Triangle	Cancel and stay in the list.

To answer it once for good, add REBOOTIOP=YES or REBOOTIOP=NO to the app's title.cfg. REBOOT_IOP also works as the key, and 1/0, TRUE/FALSE or ON/OFF as the value; any other value brings the prompt back. A conf_apps.cfg entry reads the same line from its per-app file, CFG/<ELF name>.cfg on an enabled source (for mass:APPS/MYAPP.ELF, that is CFG/MYAPP.ELF.cfg). That also applies when conf_apps.cfg and a title.cfg list the same ELF: RiptOPL keeps the conf_apps.cfg entry, so a REBOOTIOP line in title.cfg has no effect there.

POPSTARTER launches never ask: POPSTARTER.ELF and the XX., SB., EL. and SM. launcher ELFs keep their own PS1 launch path. An app on the APA HDD always gets the HDD cleanup before it starts, whichever answer you give.

Cover art for apps

Apps use the same ART/ folder as games, on the device the app itself lives on. The lookup key is the app's ELF filename rather than a game ID, so an app booting MYAPP.ELF looks for MYAPP-keyed art. The suffix convention is unchanged — see Coverflow for the naming.

An app box is square, where a PS2 case is portrait — 184×184 against 184×256 on the built-in theme — so a square image is the right shape for an app.

Troubleshooting

The app does not appear in the list. Check letter case on every path component. For title.cfg, confirm the ELF and the config file are in the same folder and that boot= names the ELF exactly. For conf_apps.cfg, confirm you are editing the file RiptOPL actually reads — a memory-card copy shadows every other one.

The app appears but will not launch. Usually the boot= filename or the path right of the = is wrong. Note that boot= is relative to the app's folder, while conf_apps.cfg paths are absolute and carry a device prefix.

Two entries for the same app. When the same ELF is registered by both methods, RiptOPL drops the scanned title.cfg entry and keeps the legacy conf_apps.cfg one — the legacy record has to keep its position, because per-app settings and Favorites are bound to it. The dropped entry still hands over its argv1 if the survivor has none.

Two conf_apps.cfg lines for one ELF are kept on purpose

Only title.cfg duplicates are removed. If your conf_apps.cfg lists the same ELF twice, both entries stay — that is your own hand-edited data, and dropping one would shift the config positions the other entries rely on. Remove the extra line yourself if you do not want it.