How to Build a Reproducible FPGA Retro-Gaming Setup
Build an FPGA retro system with documented hardware, trusted firmware and cores, lawful content, safe power/video, tested saves, and reversible updates.
An FPGA core configures programmable logic to implement a hardware design. That does not make every core transistor-accurate, cycle-perfect, or permanently compatible. HDL changes, framework updates, memory modules, video modes, controller firmware, and storage can all alter observed behavior.
A preservation-minded setup is therefore a versioned system: exact board and add-ons, trusted update sources, lawfully obtained firmware and game data, measured output, repeatable tests, backups, and a rollback path.
Step 1: define the platform and target behavior
Choose a supported platform such as MiSTer/DE10-Nano or an Analogue device and state the goal: original cartridges, openFPGA assets, low-latency HDMI, analog CRT output, development, or archival testing. These ecosystems have different file layouts, update mechanisms, licenses, and hardware capabilities.
Create an inventory before assembly:
- board/device model and hardware revision;
- SDRAM capacity/revision and other expansion boards;
- case, cooling, USB hub, storage card, network adapter;
- power supply manufacturer, model, voltage, current, polarity, and connector;
- controller/adapter models and firmware;
- display, switch/receiver/capture chain, and cables.
Photograph labels and retain receipts. Do not assume an online parts bundle matches the official electrical specification.
Step 2: assemble with power and ESD safety
Disconnect power before attaching SDRAM, I/O, USB, or other boards. Work on a nonconductive surface and follow the board maker’s ESD and standoff guidance. Check connector orientation; offset headers can damage hardware.
MiSTer’s official FAQ specifies 5 V, at least 2 A, a 5.5 mm outer/2.1 mm inner center-positive barrel connector for the DE10-Nano, with more current potentially needed for power-hungry peripherals. Match the current documentation for the exact build rather than substituting a supply based only on plug fit.
Never feed a higher voltage because an accessory is unstable, combine supplies unless the hardware documentation explicitly supports it, or power a board through multiple inputs accidentally. Use certified supplies from traceable vendors.
Step 3: prepare storage from an official image or installer
Use a new or known-good branded card with sufficient capacity. Download the platform’s official installer or firmware over HTTPS and verify the published checksum when available. Analogue firmware release pages publish an MD5 value; compare the downloaded file before copying it.
Keep the untouched download, source URL, release notes, checksum, and date in an archive. Follow the official filesystem format and placement instructions. Analogue’s update guide, for example, requires the firmware file at the card root and no second firmware file; it explicitly says not to interrupt power during the update.
Do not use preloaded cards from marketplaces as a preservation baseline. Their cores, scripts, firmware, ROMs, licenses, and modifications are unknown.
Step 4: perform a minimal first boot
Connect only required storage, one known-good controller/keyboard, power, and a direct HDMI display. Boot the menu before adding hubs, analog boards, network storage, Bluetooth, or capture equipment.
Record boot messages, framework version, displayed resolution, and card health. If video fails, MiSTer’s troubleshooting guidance starts with cable connection and storage seating before destructive reimaging. Do not repeatedly power-cycle during an active update or storage write.
Step 5: update through the project’s supported path
MiSTer documents its Downloader/Update script from the on-screen Scripts menu and notes that official updater repositories supply framework, system files, and cores. Inspect the configured repositories before running third-party “Update All” variants; an updater is executable code with network and storage access.
Analogue devices use signed or published firmware downloaded from their support pages. Follow the device-specific sequence and wait for automatic reboot.
After update, export a manifest of framework, Linux/system image, menu core, individual cores, scripts, and hashes. “Updated today” is not reproducible when upstream files can change.
Step 6: install only trusted cores and respect licenses
Use official project repositories or a core developer’s linked release. Record core name, commit/release, source URL, license, required memory/add-ons, and file checksum. A core can be open source while bundled firmware, arcade data, fonts, or ROM assets are not.
Do not run unknown shell scripts or copy opaque packs to the card. Review scripts, pin sources, and test additions on a cloned card. Keep experimental/nightly cores separate from the known-good profile and label results accordingly.
Step 7: supply firmware and game content lawfully
Dump cartridges, discs, and required firmware from hardware/media you own using lawful methods for your jurisdiction. Hash each dump and keep a read-only archive copy separate from the operational card. Do not download BIOS packs, encryption keys, arcade ROM sets, or “complete” images from unofficial sources.
Organize operational copies by documented core directory. Record region, revision, patch, and any conversion. A filename match is not proof of identical content. Never publish a support bundle containing copyrighted ROMs, firmware, per-device keys, network credentials, or NAND images.
Step 8: configure digital video from a compatible baseline
Begin with a conservative HDMI mode supported by the display. MiSTer’s video documentation describes presets, vsync_adjust, integer scaling, filters, and VRR, while warning that lower-latency modes can reduce display compatibility.
Test native core rates, 50/60 Hz families, unusual arcade refreshes, interlaced content, resolution switches, and audio. Record the full HDMI chain. A receiver or capture card can reject a mode the television accepts directly.
Change one setting at a time. Lowest theoretical latency is not useful if the display loses sync. Do not force a convenient 60 Hz by changing emulated timing.
Step 9: use analog CRT output only through documented hardware
Follow the platform’s current analog-video or Direct Video guide for compatible adapters, voltage levels, sync, color space, cable wiring, and display type. Consumer televisions, arcade monitors, VGA displays, and broadcast monitors are not interchangeable merely because a connector can be adapted.
Do not connect unverified sync or voltage to a CRT, improvise cables from pinouts without electrical testing, or open a CRT enclosure. CRTs can retain dangerous high voltage after unplugging; internal service belongs to qualified technicians. Keep a digital recovery output available while testing analog configuration.
Step 10: configure input and latency by measurement
Start with a wired, officially supported controller. Record polling/USB mode, adapters, controller firmware, core mapping, and any turbo or remap. Test all buttons, diagonals, analog ranges, multitaps, and hotkeys.
Avoid a large global deadzone to hide one worn stick. Apply the smallest correction at the appropriate device/core layer. Add Bluetooth only after wired behavior is stable, and obtain controller firmware from the manufacturer.
Measure end-to-end latency with a repeatable method if it is a project requirement. Marketing labels such as “zero lag” do not replace test conditions and results.
Step 11: validate saves and state behavior
Create an in-game save, quit through the platform’s supported menu, power down normally, reboot, and verify it. Repeat for memory cards, disk images, RTC, and core-specific writable media. Back up save directories before every framework/core update.
Treat save states or Analogue Memories as implementation-version-dependent. Analogue release notes document fixes for states across firmware versions; that history is evidence that version matters. Preserve normal game saves as the durable progress path and archive states with exact firmware/core metadata.
Step 12: build a representative acceptance suite
Choose lawful test content covering CPU timing, scrolling, sprites, audio, save media, peripherals, region modes, and known core edge cases. Include open homebrew/test ROMs when their licenses allow redistribution. Record expected behavior and compare after every update.
Test cold boot, warm reset, long session, storage write, controller reconnect, display mode switch, and clean shutdown. A single favorite game booting does not validate a multi-system setup.
Step 13: make updates reversible
Clone the working card or create a verified file-level backup before change. Keep the prior official firmware/core files and manifest. Update one layer, run the acceptance suite, and only then update controllers or video configuration.
Do not interrupt firmware installation, and do not downgrade across undocumented storage/schema changes. Use the vendor’s rollback procedure when one exists. If none exists, restore the complete known-good image rather than mixing old framework files with new cores.
Step 14: preserve the reproducibility record
Store hardware photos, inventory, power/video specifications, SD layout, configuration, firmware/core/script hashes, source URLs/licenses, content hashes/provenance, save backups, acceptance results, and known deviations. Redact Wi-Fi credentials, device keys, serials, and private network details from public copies.
Rebuild onto a spare card from the record and compare behavior. That restore test is stronger evidence than a directory listing. The setup is reproducible when another clean card and documented hardware produce the same versions, mappings, output modes, saves, and acceptance results—without relying on an unauthorized preloaded image. Related: The History of Emulation: Preserving Gaming’s Hardware Before It’s Gone · Dolphin Introduces RVZ as a Lossless, Emulation-Ready Disc Format
Sources: MiSTer official documentation, MiSTer updater guide, MiSTer hardware, power, and core FAQ, MiSTer video configuration guide, MiSTer troubleshooting guide, Analogue firmware update procedure, Analogue openFPGA introduction, Analogue firmware release notes and checksums