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.

Once the machine, media and lifecycle matter, the command line is only the final output. The launch definition also needs to describe files, firmware, generated configuration, writable state and the dependencies between them.

Author’s note

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. A historical frontend has to speak fluently to both. That’s the problem we’re solving.

Parameterize what differs. Share what doesn’t.

Archivist gives every property that genuinely varies a typed place in the launch schema: the executable, core or machine target, media slots, BIOS choice, search paths, generated configuration and lifecycle hooks. Behaviour that doesn’t vary is federated into reusable modules instead of being copied into every system.

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.

The result is a minimum-surface-area launch definition that Archivist can inspect, validate and invoke 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.

That comparison describes the products as they exist today, not what LaunchBox might support later. It illustrates two different approaches to the same problem and the trade-offs Archivist has chosen.

LaunchBox is also far more configurable than Archivist, at least for now. Archivist makes its experience as close to “one-click” as possible by being opinionated. We choose the emulator for each system, curate the One Game, One ROM collection, decide which equivalent releases to reject, and choose how IBM PC-compatible games should run. Players who enjoy comparing emulation technologies as much as the hardware they emulate may miss that control. That’s the price of reducing opportunities for a bad configuration.

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.

LaunchBox/
└── 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 recognizable 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. Your saves are in one place: easy to find, easy to browse, easy to protect—and easy to reminisce over later.

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. It’s a useful, focused workaround—and evidence that the real launch operation begins before process creation.

[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 without forking the launcher or pretending every required archive belongs to the game.

The direction of travel is encouraging. 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. Progress in emulator projects and the libretro ecosystem keeps shrinking the special-case surface that a frontend has to own.

The schema expands only where the machine demands it. Systems that need a filename stay small. Systems that need a hardware and media graph can describe the whole graph.

Pre-configured should mean complete.

Archivist's approach is better for its particular promise: making an unusually broad historical collection playable without turning every unusual machine into a research exercise. The product owns the launch knowledge, so a system definition can say what it needs and the shared modules can say how to provide it.

That produces practical benefits beyond expressive power. 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.