Virtual Memory Cards (VMC)

OPL can emulate a PS2 Memory Card using an image file stored on your game drive. This lets games save without a physical card — or lets you keep one save-file set per game rather than sharing a single real card.

Where VMC files live

VMC images are stored in a VMC/ subfolder on the same device as the game being launched. The path depends on your storage backend:

The folder must exist before OPL can create a VMC image inside it. On most devices OPL creates it for you the first time it initialises that device after you have enabled the device in Game Sources — not on first boot, so a device you have never turned on will not have one yet. If the Configure VMC screen reports an error locating the file, check that the VMC/ folder is present on the drive.

Supported sizes

OPL supports four VMC sizes, matching the storage capacities of real PS2 Memory Cards and common third-party variants:

Assigning a VMC to a game

Each game can have up to two VMC images — one for Memory Card slot 1 and one for slot 2. The assignment is stored in the per-game config (CFG/<GAMEID>.cfg as the $VMC_0 and $VMC_1 keys).

Automatic creation, cancellation and existing cards

With the VMC safety follow-ups in PR #34, a working formatter is allowed to finish even when a slow device takes more than two minutes. Back cancels the launch and requests cleanup. The menu waits up to 600 further status polls; if cleanup is still running, it stays in the menu and refuses another automatic launch while the job is busy. A blocked device call can delay a poll, so this is not a wall-clock deadline.

Before automatic reuse, and again after creation reports success, the game source must contain a readable formatted image with a complete PS2 header and matching file length and geometry. Newly created cards must also be the expected 8 MB. A changed game row or device during the progress screen cancels continuation. PS2 Favorites resolve their owning source again after the wait.

The actual loader governs existing-card handling: UDPFS and UDPBD use Neutrino, SMB uses native OPL. Native OPL requires a supported card size; Neutrino can reuse an existing formatted odd-size card. Neither path automatically reformats or deletes an existing image. These checks validate the header and geometry, not every filesystem entry or save.

The Configure VMC screen

This dialog manages a single VMC image file. It contains the following fields:

How image creation works

When you create a new image, OPL loads the genvmc IOP module and hands it the target path and size. The module formats the image in the background, writing a valid PS2 Memory Card superblock and cluster structure. The Progress bar updates live while this happens. Creation of an 8 MB VMC typically takes a few seconds on USB; larger sizes take proportionally longer.

Once the progress bar reaches 100% the button label changes to OK. Pressing OK confirms the new or updated VMC and returns you to the VMC slot picker.

Recover from a failed VMC creation

Before deleting, resizing or recreating any card that may contain saves, back up its VMC/<name>.bin file. Deleting a VMC deletes its saves; recreating one is not a safe first diagnostic.

Separate an actual creation failure (format/write error, unfinished progress or missing file) from a completed card that receives a layout warning. Check the destination path, free space, device connection and whether the share is writable. A full console restart can clear a stuck creation session, but does not change a file's on-disk fragmentation.

Report the card size, selected game core, filesystem, exact error and stage, and whether the same unchanged card works after a full restart. For Neutrino, record a fragment-budget or file-open failure separately from a native single-fragment warning. See the bug-report checklist; include VMC and PADEMU state.

Creation errors and fragmentation warnings

Creating a valid card image and placing it in a layout the launch core can use are separate steps. A newly created 8 MB file can occupy multiple extents even when the drive has plenty of free space. Free space alone does not prove contiguity.

For the native OPL core on FAT32/exFAT BDM storage, VMC writes use a contiguous sector range. RiptOPL checks the layout before enabling the card. A fragmentation prompt offers to launch with the physical memory card instead; declining returns to the menu. Do not bypass this check.

VMC %s file is fragmented. Continue with Memory Card in slot %d?

On MMCE, unsupported filesystem queries previously produced a false creation-time fragmentation warning. PR #877 distinguishes unsupported queries from a definite layout result. It does not establish that USB or internal exFAT reports have the same cause.

APA/PFS HDD: the native HDD VMC driver has its own bounded inode/block mapping. It can also display a fragmentation warning when that mapping cannot be obtained; APA is not exempt from allocation limits. Internal exFAT HDD uses the BDM path instead.

Neutrino: its BDM mapping can use multiple extents, with a shared 64-fragment budget across the game and memory-card files in the bundled runtime. A native OPL contiguity warning and a Neutrino fragment-budget failure are different checks. Record the selected core and the exact point where the error appears.

For a creation failure, record the error text/code, whether progress completed, whether the file remains, PS2 model, RiptOPL version, loader/device, FAT32/exFAT/APA filesystem, changed settings, VMC and PADEMU state. Include whether the same card works after a retry or only until reboot. See VMC troubleshooting.

Access errors at launch

If a VMC file cannot be opened at game launch — for example, because the file is missing or the drive is not ready — OPL shows:

Error accessing VMC %s. Continue with the Memory Card in slot %d?

Answering Yes tells OPL to fall back to the physical Memory Card in that slot (if present). Answering No aborts the launch.

VMC with the Neutrino core

When a game is launched via Neutrino, VMC images are passed differently. Instead of the IOP mcemu module, Neutrino receives a -mc0=<path> and/or -mc1=<path> argument pointing at the .bin file. RiptOPL builds these arguments from the same per-game $VMC_0 / $VMC_1 config keys — so if you have assigned a VMC via Game Settings it will be handed to Neutrino automatically on launch.

• USB, MX4SIO, exFAT HDD (BDM), and MMCE — VMC is passed to Neutrino via a -mcN= argument and is supported on the normal Neutrino launch path.
• iLink — the same -mcN=massN:… path is emitted, but the post-2692 iLink launch correction still needs hardware retest, so the complete launch-and-save path is not yet claimed as proven.
• UDPBD and UDPFS — the network-backed path is emitted. For UDPFS the card is a file under the PC server's shared folder (VMC/<name>.bin) and the server must not run in read-only mode, or saves fail; consult the Neutrino page for the current hardware-validation status of each network backend.
• SMB — not supported for Neutrino VMC (SMB transport is separate from BDM).
• Internal HDD (APA) — not possible: Neutrino has no APA/pfs backing store to open the .bin from (the game itself streams from raw APA via -bsd=ata -bsdfs=hdl), and a VMC must live on the same device as the game (Neutrino loads exactly one backing-store driver per launch). The game boots with whatever card is physically present, and OPL shows a warning that the configured VMC was dropped. The OPL core honors the same VMC on HDD normally.

Rules that follow from Neutrino's design: the .bin must already exist — Neutrino opens it read-write with no create and aborts the whole boot if it can't, which is why RiptOPL creates cards at config time (per-game VMC menu) and verifies at launch, skipping a missing card with a warning instead of black-screening. Bundled-runtime caveats (Neutrino's mc_emu at 7be8de2): only port 1 (-mc0) is actually emulated — -mc1 is accepted but the second port stays inactive — and the advertised card geometry is hardcoded (≈ the first 4 MB of the image is addressed). Prefer slot 1 and 8 MB cards for predictable results.

Automatic name suggestion (VMC groups)

When you open the Configure VMC dialog for a game that has no VMC assigned yet, OPL pre-fills the Name field with a suggested filename based on the game's title ID. For a large set of well-known game series (sports franchises, annual releases, and others that share save data across entries), OPL maps the title ID to a shared group ID so that all entries in the series point at the same VMC image by default — letting a FIFA 2004 save be visible in FIFA 2005, for example.

You are free to rename the VMC to anything you prefer. The suggestion is just a starting point; the actual filename written to disk is whatever name you confirm in the dialog.

Sharing VMCs across devices and builds

VMC image files are plain binary files and are not tied to any particular OPL build. A VMC created in RiptOPL can be read by stock OPL, wOPL, or uOPL — and vice versa — as long as the image is stored at the path those builds expect. Artwork, themes, VMCs, and favorites are shared between RiptOPL and other OPL variants on the same drive.