How to Configure a Multi-System Arcade Cabinet Without One Giant Global Profile

A multi-system cabinet combines furniture, mains and low-voltage power, display, audio, controls, host OS, frontend, emulators, games, service functions, cooling, and storage. The maintainable design keeps those layers separable. One enormous global profile may make the first title launch quickly, but every exception then risks breaking unrelated machines.

Define a conservative base, apply orientation/system/device profiles, and reserve per-game configuration for genuine exceptions. Document every wire and file before closing the cabinet.

Step 1: write requirements before buying controls

List target systems and lawful content, player count, button layouts, 4-way/8-way needs, analog sticks, spinners, trackballs, pedals, light guns, steering, multitaps, coin/service behavior, accessibility, display rotation, audio, networking, and maintenance access.

No panel supports every arcade control equally. A four-player digital panel should not pretend to reproduce a twin-stick, analog driving, or two-light-gun cabinet without the appropriate device. Group games by control/display profile and decide which are out of scope.

Step 2: separate mains work from low-voltage work

Use certified power supplies, power strips/inlets, switches, fuses, grounding, strain relief, and wire gauges appropriate to the jurisdiction and load. Mains wiring inside a wooden or metal cabinet belongs to a qualified electrician. Do not improvise exposed terminals, splice extension cords inside the enclosure, defeat earth ground, or power the host through undocumented GPIO.

Mount low-voltage supplies with ventilation and service clearance. Keep signal wiring away from mains, protect cables from sharp edges and hinges, and bond metal parts only according to the electrical design. Provide a documented emergency disconnect.

Step 3: make a wiring and connector schedule

Assign every switch a label: Player, control, encoder input, wire color, ground return, connector, and expected host event. Photograph both sides of the panel. Use keyed or clearly marked connectors so service cannot swap voltage and signal.

Daisy-chained ground is common for switches, but follow the encoder manufacturer’s diagram. Test continuity with power disconnected. Never guess from insulation color alone.

Keep coin and service inputs distinct. A public cabinet should not expose service mode, memory reset, emulator exit, shell, or administration through a single obvious gameplay button.

Step 4: choose encoders for stable identity

Confirm player count, USB report mode, analog support, firmware, OS driver, and whether multiple identical boards expose stable serials/IDs. Device reordering after reboot can swap players.

MAME’s controller configuration supports mapping implementation-dependent device identifiers to stable controller numbers. RetroArch also supports controller profiles and device reservations in current input documentation. Record USB vendor/product/serial and physical port, then test cold boots and reconnection.

Use official firmware utilities only. Avoid unsigned keyboard-filter or virtual-controller drivers when standard HID/SDL/XInput support is sufficient.

Step 5: build and test the host outside the cabinet

Install the OS, frontend, emulator, input profiles, display, and audio on an open bench with normal keyboard access. Use a supported package source and a non-administrator account for normal play. Apply updates and measure temperature/load before enclosure.

For Raspberry Pi hosts, use the official supply for the exact model and the documented software shutdown before removing power. For PCs, configure an OS-supported power button and automatic recovery only after testing filesystem behavior.

Do not use marketplace images containing unknown scripts, passwords, ROM sets, BIOS packs, or abandoned packages.

Step 6: choose arcade cores and ROM-set versions deliberately

Libretro’s arcade guide explains that MAME and FinalBurn cores expect distinct ROM-set versions. Pick the maintained core appropriate to the host and target games, then verify your own lawfully dumped content against that version. Randomly switching cores until a filename boots hides incomplete or mismatched sets.

Keep content manifests with hashes, dump provenance, core/version, parent/clone relationships, required firmware, CHDs, and licenses for homebrew. Do not distribute commercial ROMs with the cabinet unless rights permit it.

Step 7: create the configuration hierarchy

Keep global settings minimal: directories, safe UI, base audio, logging, and conservative display/input defaults. Then layer:

1. horizontal versus vertical display profile;
2. emulator/core family;
3. control profile such as 4-way, 8-way, six-button, trackball, twin-stick;
4. per-game exception.

MAME documents orientation, source/system, and individual configuration loading. RetroArch overrides load global, core, content-directory, then game scope, while controller remaps and shader presets use separate systems. Store only differences at the narrowest scope.

Step 8: configure digital and analog controls separately

Map general digital controls first, then system-specific exceptions. MAME exposes Input Assignments (general), Input Assignments (this system), and Analog Input Adjustments. Tune sensitivity, reverse, centering, and deadzone on the correct analog device rather than globally.

For 4-way games, use a physical restrictor or documented digital mapping; diagonal ambiguity cannot always be solved by software. Test simultaneous inputs and encoder rollover. Label special control profiles in the frontend so users know which panel/device a title expects.

Step 9: design safe service and exit controls

Use an Enable Hotkeys chord or concealed service panel for menu, pause, exit, shutdown, and maintenance. Avoid one-button destructive actions. Separate coin, start, service credit, tilt, service mode, reset, and memory reset; MAME documents these as different machine inputs.

Public mode should not expose file browser, terminal, network settings, BIOS directories, passwords, or emulator downloads. Use OS kiosk/restricted-account features rather than deleting administrative tools. Keep a physical keyboard/service route available to the owner.

Step 10: configure display and audio by system

Set Game/low-latency display mode and verify no overscan. Vertical games need a rotation/layout profile; do not globally rotate menus and horizontal systems. CRT, LCD, fixed refresh, VRR, and capture paths require different timing strategies.

Set maximum amplifier level safely, eliminate clipping/hum, and provide ventilation. Do not connect speaker outputs to line-level inputs or share unverified power grounds to cure noise.

Step 11: make shutdown and power-loss behavior explicit

A front switch should request software shutdown; it should not remove power immediately while saves or configuration are writing. Wait for the host’s documented halted state before cutting cabinet power. Add an approved UPS if abrupt outages are frequent and test its shutdown integration.

Read-only root or overlay filesystems can improve recovery on appliance builds, but saves, logs, updates, and databases still need controlled writable storage. Test what persists before adopting that design.

Step 12: secure network and update access

Disable unused services and default credentials. Bind remote administration to the trusted LAN or VPN according to the OS documentation; do not expose SSH, SMB, web admin, or RetroArch network commands directly to the internet.

Update from official sources in maintenance mode, with a rollback image. Do not let normal players invoke downloaders. Audit licenses and content manifests separately from software updates.

Step 13: back up by layer and prove restoration

Back up OS image/version, frontend database, emulator/core versions, global and scoped configs, controller profiles, shaders/overlays, playlists, saves/NVRAM/high scores, and content manifests. Protected game/firmware data should remain in a lawful private archive, not a public support bundle.

Restore onto spare storage and boot it. Test player ordering, one vertical and horizontal game, each control class, save/quit/relaunch, audio, service access, and shutdown. A backup that has not booted is only an assumption.

Step 14: run a cabinet acceptance suite

Test cold boot, repeated reboot, two/four-player simultaneous input, hotkey suppression, analog extremes, display rotation, 50/60/unusual refresh, thermal soak, network-offline mode, power-loss recovery, and full restore. Inspect cable strain and temperature after the enclosure is closed.

Keep a laminated private service map inside a locked compartment and a redacted user guide outside. The cabinet is maintainable when an exception is traceable to one scoped profile, normal players cannot reach administration, and the complete system can be rebuilt without an unauthorized preloaded image. Related: Fixing Stretched or Wrong Aspect Ratio in Emulators · Fixing Audio Crackling and Stuttering in Emulators

Sources: MAME user interface and input configuration, MAME controller configuration and stable device numbering, MAME multiple configuration files, Libretro arcade core and ROM-set planning, Libretro input and controls guide, Libretro override hierarchy, Raspberry Pi power and safe shutdown documentation