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.

ℹ 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.

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.