Repository navigation
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.
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.cfgbeside 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
| 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.
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.
The search order is:
-
mc?:OPL/conf_apps.cfg— either memory card. -
conf_apps.cfgunder 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 ordinary app ELF, from Apps or from an app in Favorites, first asks REBOOT IOP?:
| Button | Result |
|---|---|
| Configured confirm button (YES) | Reset the IOP before the app starts, so it begins with a freshly reset I/O processor. |
| Configured back button (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.
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.ELF-keyed art (for example MYAPP.ELF_COV.png). The suffix convention is unchanged — see Coverflow & PSBBN Flow
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.
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.
Source: apps.html @ 00e273e37093. Read on the documentation website.
Start here
Storage and networking
- USB, MX4SIO and iLink
- MMCE
- Internal HDD: APA and exFAT
- PSX DESR DVR (experimental)
- PC CARD CompactFlash (experimental)
- SMB shares
- Network boot: UDPFS and UDPBD
- HTTP
- NBD server
Games and features
- Neutrino core
- PS1: POPStarter and Ember
- Per-game settings
- Virtual memory cards
- GSM video modes
- In-game reset
- Cheats
- PADEMU
- RetroAchievements
- Apps
Interface and customization
- Settings reference
- Controls
- Coverflow
- Favorites
- Theme engine
- Languages
- Japanese / Unicode game titles
Help and reference
- Troubleshooting
- ZSO format
- Backward-compatible PS3
- Credits and sources
- Features in other forks
- Project overview
Detailed references
- Documentation index
- Test builds and diagnostics
- VMC creation and recovery
- PC CARD CF implementation reference
- DESR DVR implementation reference
- Per-game parental lock
- SIO2MAN hook compatibility
- Fresh-start defaults and saved settings
- APA hard disk safety and code 402
- Autolaunch and global settings
- Folders, parental lock and audio
- Language maintenance
- HTTP server conformance tools
- APA recovery tool