Experimental module loading is not a universal fix#
The recovered wiki has useful pages for IRX loading, DualShock 3 modules, and special PlayStation devices. These are advanced compatibility tools. They should not be copied into every install or used as a replacement for normal POPStarter storage setup.
IRX loader rule#
POPStarter can load up to ten IOP modules after the IOP reset, alongside the POPS IOPRP environment. The module filenames are fixed: MODULE_0.IRX through MODULE_9.IRX.
| Rule | What it means | Common mistake |
|---|---|---|
| Fixed names | Use MODULE_0.IRX, MODULE_1.IRX, and so on. | Leaving source names such as USBD.IRX when the loader expects numbered names. |
| POPS folder placement | Put modules in the backend's POPS folder, not in a VMC or per-game save folder. | Putting modules beside CHEATS.TXT and wondering why they never load. |
| Order matters | Lower module numbers load first. Dependency modules should come before modules that use them. | Loading a pad, SIO, or device module before its dependency. |
| Build behavior matters | Old WIP/RIP/prototype builds may have different loader bugs or module expectations. | Debugging a module recipe on the wrong POPStarter build. |
Placement examples#
USB:
mass:/POPS/MODULE_0.IRX
mass:/POPS/MODULE_1.IRX
mass:/POPS/MODULE_2.IRX
HDD common folder:
hdd0:/__common/POPS/MODULE_0.IRX
hdd0:/__common/POPS/MODULE_1.IRX
SMB share:
POPS/MODULE_0.IRX
POPS/MODULE_1.IRXIf a USB setup uses split folders such as POPS0 through POPS9, verify which POPS folder the launcher is actually using before assuming modules in POPS/ are inherited.
DualShock 3 notes#
The recovered DS3 page attributes the modules to belek666 and describes them as working with WIP 06 beta-era and RIP 06 builds, while warning that prototypes are affected by an IRX-loader bug. That makes DS3 support a build-sensitive experiment, not a final-r13 default promise.
| Numbered module | Recovered role | Notes |
|---|---|---|
MODULE_1.IRX | USBD.IRX | USB dependency module for the DS3 setup. |
MODULE_2.IRX | usb_pademu.irx or bt_pademu.irx | Pad emulation module; use the USB or Bluetooth variant that matches the setup. |
CHEATS.TXT | $D2LS when needed | The page ties analog/digital behavior to PS+Select and a per-game $D2LS command. |
Do not put DS3 modules into the game's VMC folder. The DS3 page is explicit that ready modules go in the POPS folder.
Special-device experiment flow#
The recovered special-device tutorial is an AKuHAK-style experiment for unusual PS1 peripherals. The pattern is to borrow matching modules from a PS2 title that supports the device, then test module order under POPStarter.
- Find a PS2 game that supports the target special device.
- Extract its
SIO2MAN.IRXand rename it toMODULE_0.IRX. - Extract the device-specific IRX modules and number them as
MODULE_1.IRX,MODULE_2.IRX, and onward. - Put the numbered modules in the POPS folder for the backend being tested.
- Test one module order at a time and record the exact build, game, device, and source title.
This is intentionally not a guaranteed recipe. Module origin, version, load order, and game behavior all matter.
Driver myth boundary#
IRX loading can help with specific input or special-device experiments. It does not mean random HDD, USB, or SMB drivers can be dropped into __common/POPS to create a new storage backend. Storage support still follows the backend rules in Storage Backends.