Ready to Launch.

Emulator, profile, platform.

Frontend launch configuration usually begins with three questions: which executable should run, which arguments should accompany it, and which platforms should use it? The answers naturally become an emulator record, one or more profiles, and an association table.

Our friends at Retrom document this model directly. An emulator declares the platforms it supports. Its launch profiles add file-extension rules and custom arguments containing a {file} placeholder. Multiple profiles let one emulator serve different platforms or modes—RetroArch can, for example, have a profile for each core—and a default profile can be chosen for each platform.

LaunchBox, one of the longest-running PC game frontends, uses a closely related association. An emulator has an application path and default parameters. Its Associated Platforms rows select cores and add platform-specific parameters. Individual games may override the command when necessary.

These are sensible designs. For the common case, the user chooses an executable, a core or profile, a platform and a ROM path. The frontend assembles the command and starts it.

A launch can be more than a command.

A cartridge console running through a libretro emulator core fits the profile model beautifully. A historical computer may need a writable disk image staged before launch. Another emulator may only read its game selection from a generated configuration file. An arcade machine may need its emulated host, attached devices, system firmware, parent software images and catalogue entry to be available at the same time.

For these systems, preparing the files and devices is part of the launch. The launch definition also needs to describe files, firmware, generated configuration, writable state and the dependencies between them.

As an example, most folks who play old games now meet them through modern ports. I recently wanted to experience Temple of Apshai on the Commodore 64, so I chose the cassette release rather than the later, much faster floppy-disk version. It felt closer to what someone might actually have played in the early 1980s if their family owned a C64 but not its expensive disk drive.

The surprise was the wait. This simple game on an 8-bit machine takes about fifteen minutes to load from tape. It’s the same sort of cassette you could rewind with a hexagonal pencil, and that some of us remember carrying children’s songs in the car. Sorry if that one stings.

Then I tried the original Wizardry: Proving Grounds of the Mad Overlord on an Apple IIe, which MAME preserves wonderfully. Most players now see the MS-DOS or later console ports. Those still look ancient, but in 1981 even their improvements would have seemed like science fiction to someone playing on a four-year-old Apple II.

The Apple II experience turns you into a disk operator. You boot from the game disk, reach the menu, follow its instructions to create a scenario disk, then swap disks while the program is still running. You label stacks of 5¼-inch floppies with masking tape and a biro, and use write-protect tabs to avoid overwriting the wrong one. Multiple drives were a luxury. Today, pulling storage out of a running program feels like a good way to crash it. Back then, it was simply how the machine worked.

MAME can preserve that whole machine, but its completeness makes it formidable. Many people bounce off the first time an arcade game asks for a coin: usually 5, then 1 for Player One, except when it isn’t. Libretro, which makes much of Archivist possible, takes a different approach by offering one interface, persistence model and control contract across dozens of systems. Archivist needs to support both approaches.

Shared launch modules

Archivist’s launch schema has typed fields for the executable, core or machine target, media slots, BIOS choice, search paths, generated configuration and lifecycle hooks. Systems use shared modules for the behaviour they have in common.

The schema documents the interdependencies too. It knows which firmware belongs to a machine, which media a slot accepts, which files may be written, and which resources must exist before launch. A system definition supplies only its concrete values and genuine exceptions.

That keeps each system’s launch definition small enough to check and use from any interface. A thousand system associations don’t imply a thousand copies of slightly different RetroArch commands that the user has to do as homework. You’re here to explore video game history, so the tool shouldn’t make you feel like you have to research and write a specification yourself just to get things running.

One save archive, whatever runs the game.

A typical frontend leaves each emulator to choose where saves, save states and configuration live. Some can redirect a save directory from the command line, but only when the emulator exposes that option cleanly. The result is several emulator-shaped silos rather than one history of the games you’ve played.

LaunchBox makes the trade-off easy to see. Its Windows edition can manage portable emulators under LaunchBox\Emulators. That’s a thoughtful design, and it lets people move a complete installation between Windows PCs by copying one folder. Each emulator still keeps its own player data: MAME puts NVRAM and save states in MAME’s tree, RetroArch keeps saves, states and configuration in RetroArch’s tree, and DOS and standalone emulators use still more sibling trees.

LaunchBox is currently available for Windows and Android—there’s no desktop Unix edition. Part of that is probably due to the complexity of moving a tightly coupled structure like that. Moving the complete Windows bundle is well supported, but that’s different from making a player’s history independent of the frontend, emulator and operating system that created it.

LaunchBox offers much more configuration and a better couch experience, backed by more than a decade of use. Archivist is aimed at exploring game history with as little setup as possible. We choose the emulator for each system, choose the best version of each release to recognise, and so on.

Archivist’s launch layer can bridge the remaining filesystem assumptions with low-level operating-system facilities such as named pipes, bind mounts or mapped drives, and process substitution. Each gives an emulator the path or file-like handle it expects while the underlying save or configuration remains in the player’s chosen archive.

Frontend/
└── Emulators/
    ├── MAME/
    │   ├── nvram/
    │   └── sta/
    ├── RetroArch/
    │   ├── saves/
    │   └── states/
    └── Standalone/

Saves/
├── Ultima 7/
├── Mass Effect 2/
├── Akalabeth/
└── Skyrim Special Edition/

Archivist lets you choose the archival structure instead. You might point it at a network-attached storage folder that’s backed up regularly, with one recognisable directory per game and everything worth keeping inside it. It doesn’t matter whether the game ran through MAME, RetroArch, a standalone emulator or Steam. You can browse your saves in one place and include them in your usual backups.

VAPF needs configuration before it launches.

VAPF is a compact standalone emulator for the APF MP-1000 and Imagination Machine, but launching it from a frontend exposes the limits of a command-only profile. The launch process must write the selected game into VAPF’s default.ini configuration file before VAPF.exe starts.

We know the integration intimately because we originally wrote the helper that made VAPF work with LaunchBox. That adapter accepts the new game path, rewrites the GAMEfilename entry in the INI file, and then starts the emulator. The helper does that preparation before starting the process.

[default.ini]
GAMEfilename = "{vault_game}"

In Archivist, those steps are the VAPF module’s pre-flight stage. They remain visible to the system launch definition, use the same resource vocabulary as every other emulator, and don’t require the user to discover and maintain a separate wrapper.

MAME starts with the machine.

A launch through the MAME emulator begins with the emulated machine. The selected game is only one part of the plan. Archivist’s system definition names the machine, attaches software to the right media slot, chooses its system firmware and exposes the paths containing parent, device and firmware archives.

One MAME machine can be a family tree:

…the computer has its ROMs

…the floppy drive has a controller

…the floppy disk is a separate image

…the keyboard may have its own firmware archive

…an expansion card or speech synthesizer can add ROMs of its own

…an arcade cabinet can add a coin hopper

…and a pinball machine adds a tilt switch. Press T in MAME to bump the table and see how it punished players who tried to cheat.

Archivist’s MAME module records those relationships directly. A simple arcade board supplies only a few values. A computer backed by a MAME software list can add its host, slot, software identity and dependency roots while keeping host and device archives separate from the game.

Emulators are simplifying some of this setup too. DOSBox once presented frontends with a similar pile of mounts, working directories, configuration and startup commands for every game. DOSBox Staging can now accept a game directory or executable directly and layer per-game configuration over shared defaults. The libretro DOSBox Pure core that Archivist uses goes further towards a console-like contract, with the game loaded as content through libretro’s shared interface. As emulators handle more of the setup themselves, frontends need fewer special cases.

Simple systems need only a filename. More involved setups use the same schema to describe their hardware and media dependencies.

Checking the launch configuration

Archivist includes the configuration for supported systems. Each system definition lists what it needs, and shared modules prepare those resources before launch.

With these dependencies recorded, configuration can be validated before launch, missing dependencies can be named, mutable state stays out of the archive, generated files have an explicit lifetime, and improvements to one module flow to every system that uses it.