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.

What is a VMC?

A Virtual Memory Card (VMC) is a .bin file that the IOP mcemu driver presents to the game as if it were a real Memory Card in slot 1 or slot 2. The PS2's kernel, and every game that reads from the card, sees an ordinary Memory Card — no special game support is required.

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:

Device	VMC folder path
USB / MX4SIO / iLink / MMCE / exFAT HDD (BDM)	`<drive root>/VMC/`
SMB (network share)	`<share root>\VMC\`
Internal HDD (APA/PFS)	`pfs0:VMC/` (default `+OPL` partition) or `pfs0:OPL/VMC/` (custom non-`+` partition). OPL reads `hdd0:__common/OPL/conf_hdd.cfg` to discover the working partition; the default is `hdd0:+OPL`.

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.

File naming

Each VMC image is a plain file named <name>.bin — for example MySaves_0.bin. The name you type in the Configure VMC dialog is the base name without extension. OPL appends .bin automatically when reading or creating the file.

Supported sizes

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

Size label	Equivalent capacity
`8 Mb`	8 MB — standard Sony Memory Card (most common)
`16 Mb`	16 MB
`32 Mb`	32 MB
`64 Mb`	64 MB — maximum supported

Size labels use "Mb" notation

The UI displays sizes as 8 Mb, 16 Mb, 32 Mb, 64 Mb — this is the notation OPL inherited from upstream. These correspond to megabyte image file sizes (8 MB file, 16 MB file, etc.). Use 8 Mb unless a specific game is known to need more space.

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

Open Game Settings

Highlight a game in the list, then press Triangle to open its options and choose Game Settings (or whichever menu entry leads to per-game options on your theme).

Enter the VMC screen

Inside Game Settings, select Configure VMC. You will see two sections: VMC Slot 1 and VMC Slot 2. Each slot shows the currently assigned VMC name (blank if none) and two action buttons.

Choose or configure the VMC

Press the name button next to a slot to open the Configure VMC dialog for that slot. Here you can type a name, choose a size, create or modify the image file, and check its status. See the Configure VMC screen section below for the full walkthrough.

Use Generic or Reset

If no custom VMC name has been assigned, the action button reads Use Generic — pressing it assigns a shared generic VMC (generic_0.bin or generic_1.bin) for that slot. If a VMC is already assigned, the button reads Reset, which clears the assignment without deleting the image file.

Save

Return to Game Settings and save. The VMC assignment is written to the per-game config and takes effect on the next launch of that game.

Or let the first launch do it

With Settings → Game Launching → Create VMC on First Launch on (it is off by default), launching a PS2 game with nothing in VMC slot 1 does these steps for you: it creates an 8 MB card on the game's own device, named as the VMC screen would suggest (every disc of a multi-disc game shares one), assigns it to slot 1 and saves the game's config before the game starts. An existing card with that name is reused, and Back during creation cancels the launch. PS1 and app rows, HTTP, and the internal APA HDD under Neutrino are skipped. Turning it on moves those games' saves off the physical memory card.

The Configure VMC screen

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

Field	What it does
Name	The base filename (no extension). OPL pre-fills a suggested name derived from the game's title ID; you can change it to any name you like. A name can be up to 31 characters.
Size	Dropdown: `8 Mb` / `16 Mb` / `32 Mb` / `64 Mb`. This is the size used when creating a new file. Existing images cannot be resized implicitly. If a file already exists at the correct size it is shown as valid; if the file exists but the size does not match it is shown as invalid.
Status	Read-only. One of: VMC file exists. (valid, ready to use), Invalid VMC file, size is incorrect. (file found but wrong size — back up the image before explicitly deleting and replacing it), or VMC file needs to be created. (no file found at that name yet).
Progress	A 0–100% progress bar that fills while a VMC is being created or reformatted. It is driven by the IOP `genvmc` module in real time.
Create / Modify / Abort / OK	The primary action button. Its label changes based on state: Create (no file yet), Modify (an existing VMC; changing its size is refused to preserve saves), Abort (creation in progress — cancels it), or OK (creation complete — dismisses the dialog).
Delete	Permanently deletes the VMC image file from the drive after a confirmation prompt. Only visible when a file exists.

Existing saves are protected

If you change the Size of an existing VMC image and press Modify, RiptOPL refuses replacement and leaves the image untouched. Back up the existing VMC/<name>.bin, then use the explicitly confirmed Delete action before creating a card of another size. An existing image with an invalid size is protected too. This does not expand a card while preserving its saves. If the image cannot be read, or the device cannot be checked reliably, creation is refused. Check the device connection and write access before trying again.

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. Duration depends on the device and allocation. Native BDM creation first reserves its allocation, writes every cluster, then synchronizes and verifies the extent and final close; a new card on the internal HDD (APA/PFS) asks PFS for all of its space before formatting. Only the incomplete file created by that job is removed on failure or cancellation. Host/image tests do not establish console save/reboot acceptance. See the creation and recovery reference.

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

New native OPL cards on FAT32/exFAT BDM storage request a single contiguous reservation before formatting. A bundled driver without the versioned capability, unsupported sector size or insufficient contiguous space fails explicitly. A new APA/PFS card asks for every zone in one request, best effort. Other core/source creation paths can allocate incrementally. Existing cards are preserved and never relocated by this request; to repair one, use Rebuild.

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. Prompts distinguish confirmed fragmentation, out-of-range disk addresses, unavailable mapping queries and native PFS block-table limits. Accepting a rejected-card prompt uses the physical card in the named slot; 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.

Preserve your saves

Back up an existing VMC before changing its allocation or recreating it. Changing the size of an existing image is refused without modifying it. Use an explicit confirmed Delete only after backing up its saves. Copying a backup back to the drive can change its layout, but does not guarantee a contiguous allocation; verify before use. Do not delete your only saved copy to try a different allocation.

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. If the combined count exceeds 64, RiptOPL reports that count and offers to skip the named VMC for the physical card. Even a contiguous card may exceed a budget already consumed by the game. 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.

Rebuild a card the native core cannot map

A card that already holds saves but is too fragmented for the native core (on BDM: more than one extent; on the HDD: a PFS map longer than native mcemu holds) is skipped at launch. The per-game VMC dialog shows it as Too fragmented for the native core and offers a Rebuild button. It appears only for a valid 8/16/32/64 MB card on a BDM (FAT32/exFAT) or HDD source whose game uses the native core, and only when the layout check gives a definite answer; Neutrino maps cards its own way, and other sources cannot say how a card lies.

After you confirm, Rebuild:

refuses to start if VMC/<name>.bak or VMC/<name>.new already exists. Either may hold saves, so neither is overwritten; move it away on a PC and try again;
creates VMC/<name>.new with the same reservation a new card gets (one extent on BDM, every zone in one request on the HDD). No room stops the job at once with Not enough unbroken free space, and nothing changes;
copies every byte of the card, reads both back and compares them, and runs the launch's own layout check on the copy;
only then swaps them: the card becomes VMC/<name>.bak and the copy becomes VMC/<name>.bin.

The card is only ever opened read-only, and the loader never deletes the card or the backup: delete VMC/<name>.bak on a PC once the rebuilt card's saves check out. If a rename cannot be undone, both .bak and .new are kept and the dialog says so; rename one of them back to .bin on a PC. If power is lost between the two renames, VMC/<name>.bak holds the card. Host tests cover every failure step on BDM and PFS; the rebuild has NOT been run on hardware. See the rebuild reference.

Saves on a card

The per-game VMC dialog has a Saves button for a card that exists. It opens a page that treats the card like a folder. From RIPPS2 builds 51 and 98 to 115 by akilluminati47; NOT TESTED on hardware. To copy saves between real memory cards and other drives, see File Manager.

On the card lists the saves by their titles, read from each save's icon.sys; Free shows the card's free space.
In the folder lists the save folders and .psu files in SAVES/, beside the card (for example mass0:/VMC/SAVES/). A .psu is listed by the save inside it, with (PSU) after its title.
Copy out copies the picked save into SAVES/<save folder>/. Copy out as PSU copies it into one file, SAVES/<save folder>.psu, the single-file save uLaunchELF, EMS and Apollo read and write; it is written to a .tmp file first and renamed only once whole. Copy in copies a folder or .psu from SAVES/ onto the card as a new save; one that does not fit is refused before anything is written, and so is a .psu that is cut short, names a file twice or uses a name a card cannot hold. None of them ever overwrites a save, folder or .psu of the same name.
Delete removes the picked save from the card after you confirm it.

SAVES/ is shared by every card in that VMC folder, so this is also how a save moves between cards. The card is edited in place; its size and place on the drive never change, so a card the native core can map stays mappable. Copy in writes the data, then the allocation table, then the entry that makes the save appear; Delete hides the entry before it frees the space. A card with ECC data, such as a PCSX2 .ps2 file, can be listed and copied out but is never changed. With writes disabled, only listing is offered.

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.

VMC names with spaces

Earlier OPL builds had a bug where VMC filenames containing spaces were truncated at launch because the args string was split on whitespace. RiptOPL delivers each -mcN= argument as a discrete argv entry, so spaces in VMC names are safe.

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 and compatible VMCs can be shared when their paths agree. Favorites import from uOPL/wOPL is one-way: RiptOPL writes its own OFAV format on the next save. Back up the original favorites file if you use other loaders.

Can I use a real Memory Card dump as a VMC?

In principle, a raw Memory Card dump in the correct PS2 format (valid superblock, matching size) should work as a VMC image — but this depends on how the dump was made. The image must contain 512-byte data pages without the physical card's ECC/spare bytes; a raw flash dump including those bytes is not directly compatible. Dumps made by software that reconstructs a logical filesystem may not match the expected superblock format that OPL validates. The safest approach is to create a fresh VMC in OPL and use a save manager (such as MyMC with a supported PS2 card image) to copy individual saves into it.

Can I assign the same VMC file to multiple games?

Yes. Because the Name field is free-form, you can type the same filename for multiple games — they will all read and write the same .bin file. This is equivalent to plugging the same physical Memory Card into the slot for every game. Useful if you want a shared pool of saves, but be aware that all games will see each other's save data and could potentially overwrite it if they use the same directory name on the card.