Ant64 Personality Cartridges
Overview
A Personality Cartridge transforms the Ant64 into a different computer entirely. Inserting a cartridge causes DeMon to reprogram FireStorm with a new FPGA bitstream — replacing the Ant64 hardware with a cycle-accurate simulation of the target machine's custom chips. The Ant64's keyboard, jog dials, display output, audio system, storage, and Colony Connection all remain available; the silicon inside FireStorm becomes something else.
The concept is not emulation in the software sense. The target machine's custom chips — its video hardware, sound hardware, bus arbitration, DMA controllers — are re-implemented as synthesised logic running in FireStorm's LUT fabric at the target system's original clock rates. The behaviour is the hardware, not a software model of the hardware. This is the same approach taken by the MiSTer and MiST FPGA projects, whose open source cores (GPL-licensed Verilog and VHDL) are the source material for the Ant64 personality cartridge builds.
The GoWin GW5AT-138k has 138,000 LUTs. The original home computers of the 1980s used between 10,000 and 30,000 gates on period silicon — a fraction of the available budget. Every personality therefore carries two modes: a faithful recreation for software compatibility, and an enhanced mode that spends the remaining LUTs on hardware the original designers would have built if silicon had been cheap. Every cartridge in this catalogue follows the same principle. Enhanced modes and their register interfaces are documented alongside each cartridge entry below.
Cartridge Format
The Ant64 cartridge slot accepts any cartridge type — personality cartridges are one category among several. Other cartridge types include game cartridges, expansion cartridges, and developer cartridges; the slot and microSD-based format are common to all. This document covers the personality cartridge type specifically.
A personality cartridge is a small cartridge shell that fits the Ant64's cartridge slot. Inside the shell is a single microSD card. That is the entire contents of the cartridge: a microSD card in a protective housing with a cartridge edge connector that DeMon reads via SPI.
There is no other electronics in the cartridge. No EEPROM, no flash chip, no MCU. The microSD card contains everything: the FPGA bitstream, OS images, ROM images, and any software titles included with the cartridge. The simplicity is intentional — the microSD card is user-accessible. The user can add ROMs, add OS images, and update the FPGA bitstream by treating the cartridge's microSD as a standard storage device from any PC.
microSD Card Directory Structure
/
├── FPGA/
│ ├── manifest.json ← Core metadata, OS files, all bitstream/component/preset definitions
│ ├── core_ant64.rbf ← Ant64 / Ant64C bitstream (GoWin 138k)
│ └── core_ant64s.rbf ← Ant64S bitstream (GoWin 60k)
├── OS/
│ ├── kickstart13.rom ← Example: Amiga Kickstart 1.3
│ ├── kickstart31.rom ← Example: Amiga Kickstart 3.1
│ └── aros.rom ← Example: free Kickstart replacement (AROS)
├── ROMS/
│ ├── game.adf ← Example: Amiga floppy disk image
│ ├── game.hdf ← Example: Amiga hard disk image
│ └── ... ← Any format the core supports
├── SAVES/
│ └── ... ← Save states, NVRAM images (written by the system)
└── ANT64/
└── config.lua ← Cartridge-specific Ant64 menu configurationmanifest.json tells DeMon everything about the card: identity, OS images,
and the complete map of configurable FPGA components — named hardware blocks
with their FRAM register addresses and valid values. DeMon and config.lua
use this map to configure the personality at boot and in response to OSD
settings, without any hardcoded knowledge of any specific core.
The manifest supports multiple bitstreams targeting different hardware models.
DeMon reads its own hardware identity at startup and selects the matching
bitstreams entry. Each entry carries its own component map, presets, and
list of machine variants — a smaller bitstream for the Ant64S with a reduced
variant set, and a fuller bitstream for the Ant64 and Ant64C. The os_files
and os_required fields are at the top level because they are shared across
all bitstreams on the card.
{
"cartridge": "Atari ST",
"core_version": "2.1.0",
"overlay_required": true,
"os_required": true,
"os_files": ["tos100.img", "tos206.img", "etos192uk.img"],
"default_os": "etos192uk.img",
"bitstreams": [
{
"file": "core_ant64s.rbf",
"targets": ["ant64s"],
"label": "Atari ST/STe (Ant64S)",
"description": "ST and STe variants — fits within the GoWin 60k LUT budget",
"components": [
{
"id": "machine_type",
"label": "Machine type",
"fram_addr": "0x1000",
"type": "enum",
"values": [
{ "value": 0, "label": "ST" },
{ "value": 1, "label": "STe" }
],
"default": 1,
"description": "ST or STe chipset variant"
},
{
"id": "blitter",
"label": "Blitter",
"fram_addr": "0x1001",
"type": "bool",
"default": true,
"requires": ["machine_type:1"],
"description": "Hardware blitter (STe only)"
},
{
"id": "ste_dma_sound",
"label": "DMA sound",
"fram_addr": "0x1002",
"type": "bool",
"default": true,
"requires": ["machine_type:1"],
"description": "STe 8-bit stereo DMA sound channel"
},
{
"id": "ste_palette",
"label": "4096-colour palette",
"fram_addr": "0x1003",
"type": "bool",
"default": true,
"requires": ["machine_type:1"],
"description": "STe 12-bit palette (4096 colours) vs ST 9-bit (512 colours)"
},
{
"id": "cpu_speed",
"label": "CPU speed",
"fram_addr": "0x1010",
"type": "enum",
"values": [
{ "value": 0, "label": "8 MHz (authentic)" },
{ "value": 1, "label": "Turbo" }
],
"default": 0,
"description": "68000 clock rate"
},
{
"id": "extra_ram",
"label": "RAM",
"fram_addr": "0x1020",
"type": "enum",
"values": [
{ "value": 0, "label": "512 KB (ST authentic)" },
{ "value": 1, "label": "1 MB" },
{ "value": 2, "label": "4 MB" }
],
"default": 1,
"description": "System RAM"
}
],
"presets": [
{
"id": "st_authentic",
"label": "ST — Authentic",
"description": "Plain ST, 8 MHz, 512 KB — maximum compatibility",
"components": {
"machine_type": 0, "cpu_speed": 0, "extra_ram": 0,
"blitter": false, "ste_dma_sound": false, "ste_palette": false
}
},
{
"id": "ste_standard",
"label": "STe — Standard",
"description": "STe with blitter, DMA sound, 4096-colour palette, 1 MB",
"components": {
"machine_type": 1, "cpu_speed": 0, "extra_ram": 1,
"blitter": true, "ste_dma_sound": true, "ste_palette": true
}
}
]
},
{
"file": "core_ant64.rbf",
"targets": ["ant64", "ant64c"],
"label": "Atari ST/STe/Mega/Extended (Ant64)",
"description": "Full variant set including Mega ST, Mega STe, and Ant64 extensions — requires 138k LUTs",
"components": [
{
"id": "machine_type",
"label": "Machine type",
"fram_addr": "0x1000",
"type": "enum",
"values": [
{ "value": 0, "label": "ST" },
{ "value": 1, "label": "STe" },
{ "value": 2, "label": "Mega ST" },
{ "value": 3, "label": "Mega STe" }
],
"default": 1,
"description": "Selects which ST-family chipset variant is active"
},
{
"id": "blitter",
"label": "Blitter",
"fram_addr": "0x1001",
"type": "bool",
"default": true,
"requires": ["machine_type:1,2,3"],
"description": "Enable hardware blitter chip (STe/Mega ST/Mega STe only)"
},
{
"id": "ste_dma_sound",
"label": "DMA sound",
"fram_addr": "0x1002",
"type": "bool",
"default": true,
"requires": ["machine_type:1,3"],
"description": "STe 8-bit stereo DMA sound channel"
},
{
"id": "ste_palette",
"label": "4096-colour palette",
"fram_addr": "0x1003",
"type": "bool",
"default": true,
"requires": ["machine_type:1,2,3"],
"description": "STe 12-bit palette (4096 colours) vs ST 9-bit (512 colours)"
},
{
"id": "cpu_speed",
"label": "CPU speed",
"fram_addr": "0x1010",
"type": "enum",
"values": [
{ "value": 0, "label": "8 MHz (authentic)" },
{ "value": 1, "label": "16 MHz" },
{ "value": 2, "label": "Turbo" }
],
"default": 0,
"description": "68000 clock rate — Mega STe supported 16 MHz natively"
},
{
"id": "cpu_ext",
"label": "CPU extensions",
"fram_addr": "0x1011",
"type": "enum",
"values": [
{ "value": 0, "label": "68000 (authentic)" },
{ "value": 1, "label": "68010 upgrade" },
{ "value": 2, "label": "68020 upgrade" }
],
"default": 0,
"description": "Optional CPU instruction set extension — see personality_cpu"
},
{
"id": "extra_ram",
"label": "RAM",
"fram_addr": "0x1020",
"type": "enum",
"values": [
{ "value": 0, "label": "512 KB (ST authentic)" },
{ "value": 1, "label": "1 MB" },
{ "value": 2, "label": "4 MB" },
{ "value": 3, "label": "14 MB (DDR3 expansion)" }
],
"default": 1,
"description": "System RAM — values above 4 MB use FireStorm DDR3"
},
{
"id": "enhanced_sprites",
"label": "Enhanced sprites (Ant64 Extended)",
"fram_addr": "0x1030",
"type": "bool",
"default": false,
"description": "64-sprite hardware layer — not present on original hardware"
},
{
"id": "extended_palette",
"label": "24-bit palette (Ant64 Extended)",
"fram_addr": "0x1031",
"type": "bool",
"default": false,
"description": "Full 24-bit palette alongside the original hardware palette"
},
{
"id": "rtc",
"label": "Real-time clock",
"fram_addr": "0x1040",
"type": "bool",
"default": true,
"requires": ["machine_type:2,3"],
"description": "Mega ST / Mega STe built-in RTC"
}
],
"presets": [
{
"id": "st_authentic",
"label": "ST — Authentic",
"description": "Plain ST, 8 MHz, 512 KB, 512 colours — maximum compatibility",
"components": {
"machine_type": 0, "cpu_speed": 0, "cpu_ext": 0, "extra_ram": 0,
"blitter": false, "ste_dma_sound": false, "ste_palette": false,
"enhanced_sprites": false, "extended_palette": false, "rtc": false
}
},
{
"id": "ste_standard",
"label": "STe — Standard",
"description": "STe with blitter, DMA sound, 4096-colour palette, 1 MB",
"components": {
"machine_type": 1, "cpu_speed": 0, "cpu_ext": 0, "extra_ram": 1,
"blitter": true, "ste_dma_sound": true, "ste_palette": true,
"enhanced_sprites": false, "extended_palette": false, "rtc": false
}
},
{
"id": "mega_ste",
"label": "Mega STe — 16 MHz",
"description": "Mega STe with 16 MHz CPU, blitter, DMA sound, 4 MB, RTC",
"components": {
"machine_type": 3, "cpu_speed": 1, "cpu_ext": 0, "extra_ram": 2,
"blitter": true, "ste_dma_sound": true, "ste_palette": true,
"enhanced_sprites": false, "extended_palette": false, "rtc": true
}
},
{
"id": "ant64_extended",
"label": "Ant64 Extended",
"description": "STe + 64 sprites + 24-bit palette + 14 MB + 68020 extensions",
"components": {
"machine_type": 1, "cpu_speed": 2, "cpu_ext": 2, "extra_ram": 3,
"blitter": true, "ste_dma_sound": true, "ste_palette": true,
"enhanced_sprites": true, "extended_palette": true, "rtc": false
}
}
]
}
]
}How the component system works
DeMon reads the bitstreams array at boot, identifies its own hardware
model (Ant64S, Ant64, or Ant64C), and selects the entry whose targets list
matches. It then programs FireStorm with that entry's .rbf file and applies
the component defaults by writing each fram_addr register. If no saved
configuration exists, the first preset in the matched entry's presets list
is applied. The requires field lists which component values must be active
for a given component to be valid — DeMon enforces dependencies automatically:
enabling ste_dma_sound when machine_type is 0 (ST) would silently have no
effect, so the requires field prevents the combination from being presented in
the OSD.
config.lua reads the component map and presets from the matched
bitstream entry and builds the OSD settings menu dynamically. Every component
becomes an OSD control matched to its type: bool → toggle, enum →
selector. Presets become named shortcuts at the top of the menu. The Lua
script never needs hardcoded knowledge of any specific core — it reads the
manifest entry that DeMon selected and constructs the menu from what that
bitstream declares itself to support. An Ant64S sees the two-variant ST/STe
menu; an Ant64 sees the full four-variant menu with Ant64 Extended options.
The same config.lua handles both without modification.
This means the OSD menu for every personality is generated entirely from
manifest.json. A new core with new components requires only an updated
manifest; no changes to DeMon firmware, AntOS, or the Lua host are needed.
OSD theming — as config.lua matures, it can adopt a visual theme
appropriate to the simulated machine. The Atari ST personality's OSD might
use the TOS GEM desktop aesthetic — the familiar grey panels and drop shadows
of the Atari desktop. The Amiga personality could use Workbench colours and
Topaz-style typography. The Arcade Cartridge could present its system selector
as a cabinet marquee browser with the artwork of each system. The C64
personality might render the OSD in PETSCII on a blue background. These are
cosmetic layers on top of the same underlying component data — the theme is a
property of config.lua and can be updated independently of the bitstream or
the manifest. A theme is just a set of colour, font, and layout preferences
that config.lua applies when it detects the cartridge type from the manifest's
"cartridge" field.
Changing a component at runtime — OSD changes write the new value
directly to the appropriate FRAM register via DeMon. The FPGA fabric responds
to the register write immediately; most component switches (speed, palette
mode, RAM size) take effect within one frame. A component that requires a
machine reset to take effect sets "reset_required": true in its definition,
and config.lua presents a "Reset and apply" confirmation before writing.
The Arcade Cartridge uses the same mechanism: each bitstream in the FPGA directory has a corresponding component block in its manifest entry, describing the DIP switch equivalents and configuration options for that arcade system. Selecting a different coin-up timing, screen orientation, or difficulty level writes the appropriate FRAM register.
Boot Sequence With a Cartridge Inserted
DeMon detects cartridge insertion via the slot's presence pin. The sequence:
-
DeMon reads
manifest.jsonfrom the cartridge microSD. Validates the core version, loads the component map and preset definitions, and applies the last-used configuration (stored inANT64/config.luastate) or the default preset if no saved state exists. -
DeMon reprograms FireStorm via QSPI with
FPGA/core.rbf— the target machine's custom chip implementation. FireStorm reconfigures in ~200ms. The Ant64 hardware ceases to exist in silicon; the target machine's hardware takes its place. -
Ant64 Interface Block active — every personality bitstream includes the Ant64 Personality Interface Block as a standard HDL module compiled into the Verilog for that personality. It is not a reserved or protected section of fabric; it is code that the personality developer includes in their design and that synthesises into the bitstream alongside the chipset. It provides: the QSPI FRAM slave, DeMon communication bridge, OSD/menu overlay generator, HDMI output mux, audio DSP and DAC routing, debug register bank, and rewind capture block.
-
CPU softcore active — the bitstream includes the target machine's CPU as synthesised logic in the GoWin fabric alongside the custom chip implementation. See personality_cpu for the full microarchitecture: zero-wait-state SRAM replacing original DRAM, pipelined execution, optional cycle-accurate throttling. No action is required on the SG2000 — the CPU is entirely in the FPGA.
DeMon optionally loads a debug and development application onto the SG2000 big core (C906) at this point. When loaded, the debug app has full read/write access to the softcore's registers, system RAM, and custom chipset registers via the QSPI FRAM interface. See the Debug and Development section.
-
OS image loaded — DeMon reads the default OS file from
OS/and loads it into the appropriate memory region (as configured by the core). For machines that require a ROM (Amiga Kickstart, C64 KERNAL, etc.) this is the ROM image. For machines with no ROM requirement the OS folder may be empty. -
Target machine boots — from this point the Ant64 is the target machine. The keyboard maps to the target machine's keyboard. The display output is the target machine's video signal, scaled to DisplayPort (4K/60), HDMI (1080p), and VGA simultaneously via the Interface Block's line buffer. The audio routes through FireStorm's audio DSP to the speakers. The cartridge microSD's
ROMS/folder is accessible via the OSD as a disk/tape/cartridge image source. -
Ant64 overlay available at any time — pressing the dedicated Reset function key brings up the Ant64 OSD over the running target machine. From the OSD the user can: load a different disk/ROM image from
ROMS/, save or restore a save state toSAVES/, change core configuration, or eject the personality and return to AntOS.
CPU Implementation
All personality cartridge CPUs are implemented as synthesised softcores inside the GoWin GW5AT-138k fabric — not software running on the SG2000. The target CPU and all companion chips are optimised microarchitectures that run the original instruction set faithfully but are unconstrained by the transistor budgets, memory speeds, and bus limitations of the original era.
The full CPU architecture — zero-wait-state SRAM, pipelined execution, barrel shifters, independent instruction and data buses, optional cycle-accurate throttling, and speed multiplier tables for every supported platform — is documented in personality_cpu.
The GoWin GW5AT-138k has 138k LUTs. The complete chipset for a typical 8-bit machine (CPU + video + sound + I/O) occupies 8–20k LUTs. A full 16-bit system such as an Amiga 500 ECS occupies approximately 20k LUTs. The 138k budget comfortably accommodates any single platform plus the Ant64 Personality Interface Block, with substantial LUT budget remaining for the enhanced modes described later in this document. Multiple complete systems can coexist in a single bitstream simultaneously — see personality_cpu for multi-system bitstream configurations.
The SG2000 small core runs AntOS alongside the personality at all times. The SG2000 big core (C906, 1GHz) is available to run an optional debug and development application — with full read/write access to the softcore's registers, system RAM, and custom chipset registers via the QSPI FRAM interface. See the Debug and Development section below.
Controller and Joystick Ports
The Ant64 has four front-facing DE-9 joystick/paddle ports compatible with Atari and Sega joystick standards — the most common interface on 1980s home computers and consoles. In personality mode these ports connect to the running softcore as if they were the original machine's own controller hardware. USB gamepads and joysticks are also supported and can be configured to simulate classic controllers via AntOS settings or per-cartridge settings stored in manifest.json.
Direct Mapping — Machines With Native DE-9 Ports
For machines that already used DE-9 joysticks, the Ant64's ports map directly with no adapter required:
| Machine | Native ports | Ant64 mapping |
|---|---|---|
| Atari 8-bit (400/800/XL/XE) | 4 × DE-9 | All 4 ports map directly — a genuine 4-player machine |
| Commodore 64 / 128 | 2 × DE-9 | Ports 1–2 direct; ports 3–4 via extended mapping |
| Amiga (all models) | 2 × DE-9 | Ports 1–2 direct; ports 3–4 via extended mapping |
| Atari 2600 / 7800 | 2 × DE-9 | Ports 1–2 direct; ports 3–4 via TIA or MARIA extended I/O |
| Sega Mega Drive / Genesis | 2 × DE-9 | Ports 1–2 direct; ports 3–4 via extended mapping |
| Sega Master System | 2 × DE-9 | Ports 1–2 direct |
The Atari 8-bit is the cleanest case — POKEY already handles all four ports natively and the Ant64's four physical ports map to them one-to-one at no implementation cost.
Extended Mapping — Machines Without Native Multi-Port Support
For machines that had fewer than four controller inputs, ports 3 and 4 are made available via memory-mapped registers in the softcore. The mapping is a manifest.json component — enabled by default where it doesn't conflict with original hardware, and AntOS or the OSD allows it to be configured or disabled for maximum compatibility with software that probes the original port addresses.
Where possible, the extra ports are mapped into gaps in the machine's existing I/O address space — partially decoded addresses that the original hardware never responded to, making the extensions naturally compatible with software that doesn't know about them:
| Machine | Standard ports | Extended port mapping |
|---|
| Commodore 64 | CIA 1 $DC00/$DC01 | Ports 3–4 at $DC02/$DC03 — adjacent unused CIA registers |
| Amiga | CIA A/B $BFxxxx | Ports 3–4 using spare CIA I/O lines in the $BFxxxx space |
| BBC Micro | Analogue ADC + user port | Ports 3–4 at $FC10/$FC11 in the 1MHz bus expansion space |
| NES / SNES (Nintendo) | $4016/$4017 | Ports 3–4 at $4018/$4019 — adjacent in the APU/IO region, shared between both modes |
| Atari ST | $FFFC00/$FFFC02 (IKBD) | Ports 3–4 at $FFFC08/$FFFC0A in the IKBD address space |
| ZX81 / ZX80 | None | Kempston-compatible at $1F/$37 |
The addresses shown are the defaults. Any of these can be reconfigured or disabled via the OSD. A game or application that was written for a specific joystick interface will find its expected register at the expected address; software that wasn't written with extra ports in mind simply never reads the extended addresses.
Paddle and Analog Input
The DE-9 paddle standard uses a potentiometer on pins 5 and 9. The Ant64's ports read analog values from these pins and present them to the softcore as the original machine's analog input hardware:
- Atari 8-bit — four paddles per port (two ports, eight total paddles) routed through POKEY's POT inputs as on original hardware
- C64 — two paddles per port routed through the SID's POT registers at
$D419/$D41A - Amiga — mouse ports double as paddle inputs; analog values accessible at
$DFF00A(JOYDAT0) and$DFF00C(JOYDAT1) - Atari ST — analog joystick values routed through the IKBD's analog input registers
USB Controller Mapping
USB gamepads and joysticks connected to the Ant64's USB ports appear alongside the DE-9 ports. Pulse — the music sequencer RP2350 that also handles joypad inputs, USB ports, and MIDI ports — presents all controller data to the personality via FRAM registers alongside the physical DE-9 port data. AntOS presents a controller configuration screen where any USB device can be assigned to any of the four logical controller slots. A mapping profile can be stored in ANT64/config.lua on the cartridge microSD so the configuration is automatic when that cartridge is inserted — a USB Xbox-style pad automatically mapping to the correct buttons for each specific game or machine.
USB controllers assigned to a slot drive the same FRAM registers as the physical DE-9 ports, so the softcore sees no difference between a physical DE-9 joystick and a USB gamepad mapped to the same slot.
MIDI controllers connected to Pulse's MIDI ports can similarly be mapped to controller slots or to the target machine's MIDI interface where one exists — the Ant64C's DIN MIDI ports connect directly to Pulse.
The Ant64 Personality Interface Block is a standard HDL module — pre-written, verified Verilog supplied to personality developers — that they include in their design and compile into their bitstream alongside the chipset implementation. It is not a reserved or protected region of the FPGA; it is ordinary synthesised logic that happens to be the same across every personality because every personality includes the same module. Its LUT cost comes from the 138k budget like any other logic in the bitstream. It provides consistent Ant64 functionality across all personalities:
OSD generator — composites the Ant64 menu overlay on top of the target machine's video output. The OSD uses the same ImGui-style rendering as AntOS but simplified to the overlay context: file browser, core settings, save state management, return-to-AntOS option.
Video output — line buffer interface
The personality's entire obligation for video output is to supply one scanline of pixels at a time into the Interface Block's line output buffer. Everything beyond that — scaling, encoding, splitting to multiple displays, and per-display post-processing — is handled by the Interface Block automatically.
The Ant64 drives three video outputs simultaneously from the same source:
- DisplayPort — 4K/60 Hz via FireStorm's high-speed transceivers (Ant64 and Ant64C only)
- HDMI — 1080p via differential lines
- VGA — 5-5-5 (15-bit colour) via DAC/resistor arrays, compatible with any analog RGB monitor or SCART display
All three outputs are scaled from the same source scanline. Each output has its own independent post-processing configuration — scanline simulation, aperture grille, CRT curvature, integer scaling — settable separately per output from the OSD. A user can have crisp nearest-neighbour scaling on the DisplayPort 4K display while simultaneously having heavy scanline simulation on the VGA output connected to a CRT monitor, both driven from the same personality scanline data.
Because the line buffer receives each scanline after the chipset hardware has finished generating it — including all mid-frame and per-line register changes — every scanline effect produced by the original hardware is reproduced with full accuracy before scaling occurs. The Copper writing a new colour at line 127, the Spectrum ULA changing the border colour mid-frame, a C64 raster interrupt changing the background at a specific line, an Amiga screen split changing display modes between scanlines — all produce correct pixel data in the scanline arriving at the line buffer. Scaling and output happen to already-correct pixel data. A software emulator that scales before or during rendering, or whose video hardware is not cycle-accurate, will produce these effects incorrectly or at the wrong display position. On the Ant64 there is no such problem — the scanline is what the original hardware would have produced, cycle for cycle.
The personality developer connects the chipset's pixel output to the line buffer input — the same connection regardless of target resolution, pixel clock, or display format. The Interface Block handles PAL/NTSC timing, scan-doubling for VGA, upscaling for 1080p and 4K, sync generation for all three outputs, and OSD compositing. A 15kHz PAL Spectrum or a 13MHz NTSC Amiga scanline arrives at the line buffer and leaves simultaneously as 4K, 1080p, and VGA — the personality is unaware of any of this.
Audio bridge — the target machine's audio output passes through FireStorm's audio DSP chain and the codec connected directly to FireStorm to the speakers and audio outputs. The environmental DSP system is available as an optional layer — applying room reverb to Amiga Paula audio, for example, is a single OSD toggle.
DeMon bridge — maintains the DeMon ↔ FireStorm communication channel throughout the personality session. DeMon can monitor system state, handle cartridge microSD I/O requests from the core, and respond to the eject command from the OSD.
Save state interface — the overlay block co-ordinates save state
captures: freezing the softcore via the Personality Interface Block
halt signal, reading CPU registers and custom chip state from the FPGA fabric
via the debug register bank, and writing the snapshot to SAVES/ on the
cartridge microSD.
Rewind capture — the Personality Interface Block includes a hardware rewind capture block that records CPU register changes, RAM writes, and chipset register writes as XOR delta frames into a ring buffer in FireStorm DDR3, with zero impact on CPU clock speed. The same stored entry applies for both undo and redo — directionality is entirely determined by which way the ring buffer pointer moves.
Cartridge Catalogue
Home Computer Cartridges
Amiga Cartridge
Target systems: Amiga 500, Amiga 600, Amiga 1200, Amiga 4000, Amiga CD32
FPGA core: Minimig-AGA Source: github.com/MiSTer-devel/Minimig-AGA_MiSTer Licence: GPL v3 CPU mode: Softcore (optimised 68000/68020 in FPGA fabric — see personality_cpu)
Chipset support:
- OCS (Original Chip Set) — Amiga 500 / 1000
- ECS (Enhanced Chip Set) — Amiga 500+, 600
- AGA (Advanced Graphics Architecture) — Amiga 1200 / 4000
- AAA (Advanced Amiga Architecture) — Ant64 extended mode; unified OCS/ECS/AGA/AAA register map
The Minimig core is the most mature open source Amiga FPGA implementation, originally developed by Dennis van Weeren in 2005 and maintained continuously since. The MiSTer-devel variant adds AGA support, Kickstart 1.2 through 3.2 compatibility, IDE hard disk image support, and ADF floppy image support.
OS folder contents:
kickstart13.rom— Kickstart 1.3 (user must supply; copyrighted by Amiga/Commodore)kickstart31.rom— Kickstart 3.1 (user must supply)aros.rom— AROS Kickstart replacement (free, included on card)
The AROS Kickstart replacement provides a legal boot environment without requiring the user to supply a Kickstart ROM. Compatibility is high for OCS/ECS titles; AGA titles generally require genuine Kickstart 3.1.
ROMS folder: ADF floppy images, HDF hard disk images. The OSD file browser presents these as the Amiga's internal disk drive and hard disk respectively.
Configuration options (OSD):
- Chipset: OCS / ECS / AGA / AAA (unified bitstream — see Enhanced Mode below)
- CPU: 68000 / 68020 / 68020+FPU / 68030 / 68040 / 68060
- CPU speed: original / 2× / 4× / turbo
- Chip RAM: up to 8MB — both 1M × 32-bit SRAM banks are interleaved across a unified chip RAM address space; even addresses on one bus, odd addresses on the other. The Amiga's bitplane DMA and blitter are almost perfectly sequential, so interleaving gives near-double bandwidth for DMA-intensive operations. CPU accesses are routed by address parity with no arbitration cost. No contention between DMA and CPU — ever.
- Fast RAM: 0 / 64MB / 256MB / 1GB+ — FireStorm DDR3, CPU-only bus, no DMA access; effectively unlimited fast RAM by original Amiga standards
- Kickstart ROM selection from OS/ folder
- Floppy speed: 1× / 2× / 4× / turbo
- Video outputs: DisplayPort 4K, HDMI 1080p, VGA — all simultaneous via Interface Block
The enhanced mode for the Amiga cartridge is AAA — described in full below. The key additions over authentic AGA operation are:
Unified OCS/ECS/AGA/AAA register map — AGA software runs transparently on AAA hardware via a translation layer. No software changes required.
Extended palette and colour depth — Monica's HAM-10 mode provides 16.8 million simultaneous colours, accessed automatically by AGA software via the HAM-8→HAM-10 translation layer.
Chip RAM — both 1M × 32-bit SRAM banks are interleaved as a unified 8MB chip RAM address space, with near-double bandwidth for the Amiga's sequential DMA access patterns. Fast RAM is the FireStorm DDR3 pool (1 GB on Ant64, ~2 GB on Ant64C), CPU-only, shared with the rewind buffer. A personality option controls the fast RAM / rewind split — see the Rewind section for the tradeoff table.
AAA — the chipset Commodore never shipped
The AAA chipset (Advanced Amiga Architecture) was Commodore's planned successor to ECS — not to AGA. AGA was an unplanned intermediate step shipped in 1992 as a stopgap while AAA was delayed; AAA was designed from the ECS register base and predates AGA as a design. The two have overlapping capability — both offer 24-bit colour, extended sprites, and chunky pixel modes — but via completely different register maps. Design started in 1988; first silicon was fabricated in 1992–1993 on three Nyx prototype boards. The project died when Commodore ran out of money for chip revisions before a functioning production version was completed — not because the design was unsound.
More is documented about AAA than most unshipped chipsets. Dave Haynie's technical overview survives and covers the register map in detail. The four chips were:
- Andrea — replaces Agnus/Alice. Bus controller with a 32-bit blitter that handles chunky pixels, 40 on-demand dynamically allocated DMA channels, and an asynchronous CPU interface that decouples the pixel clock from the bus clock entirely.
- Linda — a line-buffer chip with double buffering supporting resolutions up to 1280×1024, with per-line pixel clock selection enabling clean screen mode mixing without display artefacts.
- Monica — replaces Denise. Display controller with HAM-8 (262,144 colours) and HAM-10 (16.8 million colours) modes, sprites up to 128 pixels wide, and direct 16-bit chunky pixel output.
- Mary — replaces Paula. 8-channel 16-bit audio at up to 100 kHz, improved floppy controller, and dual buffered UARTs.
A unified register map — OCS/ECS/AGA/AAA in one bitstream
Because both AGA and AAA descend from ECS, the ECS register base is common ground to both. AGA extended ECS registers in place; AAA added new register blocks at new addresses. On the FPGA both register sets coexist simultaneously:
$DFF000–$DFF1FF — ECS/AGA compatible registers (all modes)
$DFF200–$DFF3FF — AGA extended registers
$E00000–$E01FFF — AAA new registers (Andrea/Monica/Linda/Mary)A translation layer means AGA software gets AAA hardware executing its register writes transparently — palette, blitter, Copper, HAM-8→HAM-10, and audio all translate cleanly. Both sprite engines (AGA 16-pixel and AAA 128-pixel) run simultaneously in the same frame, feeding the same priority/compositing layer:
| Software | Sprites | Palette | Blitter | Audio |
|---|---|---|---|---|
| OCS/ECS/AGA software | 8 AGA sprites (16px), Monica deeper colour | Monica CLUT | Andrea 32-bit | Mary 16-bit |
| AAA software | Monica wide sprites (128px) | Monica CLUT | Andrea 32-bit | Mary 16-bit |
| New Ant64-specific software | Both simultaneously — 8 narrow + Monica wide, combined priority | Full Monica | Andrea 32-bit | Mary 16-bit |
CPU pairing — because Andrea's asynchronous interface decouples the chipset entirely from the CPU bus, the AAA chipset works with any CPU. On the Ant64 the AAA personality pairs with the 68030/68040/68060 softcore with full 32-bit addressing.
Ant64 hardware advantage — chip RAM bus contention eliminated
The Ant64 personality resolves the Amiga's defining architectural constraint entirely. In the original A500, Agnus owns chip RAM and the 68000 gets at most half the bus bandwidth — less during active DMA. On the Ant64, both 1M × 32-bit SRAM banks (8MB total) are interleaved as a unified chip RAM address space — even addresses on one bus, odd addresses on the other. The Amiga's bitplane DMA and blitter are almost perfectly sequential, so interleaving gives near-double chip RAM bandwidth for DMA-intensive operations. The CPU's accesses are routed by address parity with trivial memory controller logic. Agnus DMA and CPU can both be active simultaneously with no contention and near-double the bandwidth of a single bank. Fast RAM is the FireStorm DDR3 pool on its own separate bus, CPU-only, with no DMA access.
A program that ran in fast RAM on the original Amiga to escape chip RAM contention runs at the same speed in chip RAM on the Ant64. The distinction between chip RAM and fast RAM, which shaped Amiga programming for a decade, ceases to matter.
Paula's audio channels can be routed through FireStorm's audio DSP post-processing chain, adding reverb, EQ, and modern stereo imaging to the original Paula output. Denise's video output is composited by FireStorm's rasterizer, enabling scanline filters, integer scaling, and overlay graphics. The Copper's register writes can be mirrored to FireStorm's layer system. AntOS networking gives the recreated Amiga access to the gossip P2P mesh.
WHDLoad and Picasso96 — the Amiga personality supports WHDLoad installations on the ROMS/ HDF image natively — the OSD file browser shows WHDLoad-installed games alongside ADF disk images. The overlay block provides a virtual Picasso96 RTG card — and since Monica's chunky pixel modes are exactly what Picasso96 expects from RTG VRAM, the same translation layer that maps AGA register writes to AAA hardware also maps Picasso96 writes to Monica's chunky framebuffer. Picasso96-compatible Amiga software (Workbench 3.x in hi-colour, Photogenics, applications using custom screen modes) gets Monica's native chunky pixel output at resolutions the original Amiga chipset could never produce — without any change to the Picasso96 driver or the software using it.
No complete implementation of AAA exists in any form. The Nyx prototype boards were never fully operational; fully functioning AAA chips were never produced; no software has ever run on a complete working AAA system. When realised, the Ant64 Amiga cartridge would be the first complete AAA Amiga simulation in existence.
Atari 16/32-bit Cartridge
Target systems: Atari ST, Mega ST, STe, Mega STe, TT, Falcon030
FPGA core: Combined ST/STe/TT/Falcon030 bitstream Reference sources:
- github.com/MiSTer-devel/AtariST_MiSTer — GPL v3
- hatari-emu.org — GPL (Falcon hardware reference) CPU mode: Softcore (68000 for ST/STe; 68030 for TT/Falcon — both in fabric) Ant64S: Not supported — combined bitstream requires ~65–80k LUTs, exceeding the Ant64S 60k fabric
The Atari ST, STe, TT, and Falcon030 share a deep hardware lineage — each machine is a direct evolution of the one before it. This makes them natural candidates for a single combined personality bitstream rather than four separate cartridges. Common components (the YM2149 sound chip and MFP 68901 multi-function peripheral) are shared as single instances across the whole range. The 68000 (ST/STe) and 68030 (TT/Falcon) coexist as separate softcores within the same bitstream. Switching between ST, STe, TT, and Falcon modes is instant via the OSD with no bitstream reload — the same mechanism used for any multi-system bitstream. See personality_cpu for the combined LUT budget breakdown and the full rationale.
The shared chipset lineage
- ST — GLUE, MMU, Blitter, Shifter, MFP 68901, YM2149. The baseline.
- STe — enhanced Shifter with 4096-colour palette and hardware scrolling, DMA stereo sound, Microwire/LMC1992 audio mixer, hardware sprites. The ST chipset augmented rather than replaced.
- TT — 68030, second MFP, TT Shifter with extended resolutions, SCSI, 32-bit TT-RAM.
- Falcon030 — 68030 + MMU + optional FPU, Videl video chip (262144 colours, 16-bit high-colour mode), Motorola DSP 56001, Crossbar audio routing matrix, IDE. The most complex machine in the range.
The Falcon and the serialisation problem
Hatari (hatari-emu.org), the GPL software reference for the Falcon, requires a host machine of over 2 GHz to emulate the Falcon in software. This is because a software emulator must serialise everything that ran in parallel on the original hardware — the 68030, DSP 56001, Videl, and SDMA all executing simultaneously on the original machine become sequential context switches in software. On the FPGA all four blocks run as actual parallel hardware — architecturally closer to the original than any software emulator can be by definition.
The Ant64 personality also resolves the Falcon's defining hardware frustration: the DSP 56001 and 68030 competing for the same memory bus on the original machine. On the Ant64 both run as parallel hardware blocks on independent SRAM buses with no contention. The DSP 56001 maps naturally onto FireStorm's audio DSP pipeline — the Falcon's Crossbar audio routing and effects chain can be extended with FireStorm's own reverb, EQ, and spatial processing, running simultaneously with original DSP code. The Falcon was one of the first affordable DAW platforms; on the Ant64 it becomes considerably more capable than Atari ever shipped.
The Falcon030's custom chips — Combel, Videl, and SDMA — are being
reverse-engineered by the community. The ST and STe are deliverable ahead of
the full Falcon implementation; the combined bitstream architecture means the
Falcon components are added into the same bitstream as they mature, and the
manifest's status field marks each subsystem's readiness individually.
OS folder contents:
tos100.img— TOS 1.00 (ST; user must supply)tos206.img— TOS 2.06 (ST/STe)tos306.img— TOS 3.06 (TT; user must supply)tos404.img— TOS 4.04 (Falcon; user must supply)etos1024k.img— EmuTOS 1024k (free, covers all machines; included)
EmuTOS is a GPLv2-licensed free TOS replacement included on the cartridge. Its 1024k variant supports all four machines in the combined bitstream. Users may add genuine TOS images for titles that require a specific version.
ROMS folder: ST/STe floppy images (.st, .msa, .stx), TT and Falcon disk images (.img, .hdf), hard disk images for all machines.
Combined manifest — all four machines, one cartridge
The manifest for the combined Atari cartridge declares all four machines as
configurations of a single bitstream. The machine_type component at the
top level selects the active system; all other components are gated by
requires on the relevant machine types. The Atari ST manifest example in the
previous section shows the ST/STe component set in detail. The Falcon
components and their status flags are shown below, demonstrating how
in-development Falcon subsystems coexist with stable ST/STe components in the
same manifest:
{
"cartridge": "Atari 16/32-bit",
"variant": "ST / STe / TT / Falcon030",
"core_version": "1.0.0",
"overlay_required": true,
"os_required": true,
"os_files": ["tos100.img", "tos206.img", "tos306.img", "tos404.img", "etos1024k.img"],
"default_os": "etos1024k.img",
"components": [
{
"id": "machine_type",
"label": "Machine",
"fram_addr": "0x1000",
"type": "enum",
"status": "stable",
"values": [
{ "value": 0, "label": "ST" },
{ "value": 1, "label": "Mega ST" },
{ "value": 2, "label": "STe" },
{ "value": 3, "label": "Mega STe" },
{ "value": 4, "label": "TT" },
{ "value": 5, "label": "Falcon030" }
],
"default": 2,
"description": "Active Atari machine — switches instantly with no bitstream reload"
},
{ "id": "blitter", "fram_addr": "0x1001", "type": "bool",
"status": "stable", "default": true,
"requires": ["machine_type:1,2,3,4,5"],
"description": "Hardware blitter (not present on base ST)" },
{ "id": "ste_palette", "fram_addr": "0x1003", "type": "bool",
"status": "stable", "default": true,
"requires": ["machine_type:2,3,4,5"],
"description": "4096-colour STe palette" },
{ "id": "ste_dma_sound", "fram_addr": "0x1002", "type": "bool",
"status": "stable", "default": true,
"requires": ["machine_type:2,3,4,5"],
"description": "STe 8-bit stereo DMA sound" },
{ "id": "tt_shifter", "fram_addr": "0x1050", "type": "bool",
"status": "stable", "default": true,
"requires": ["machine_type:4"],
"description": "TT extended video resolutions and palette" },
{ "id": "tt_scsi", "fram_addr": "0x1051", "type": "bool",
"status": "beta", "default": true,
"requires": ["machine_type:4"],
"description": "TT SCSI interface" },
{ "id": "videl_standard","fram_addr": "0x2010", "type": "bool",
"status": "beta", "default": true,
"requires": ["machine_type:5"],
"description": "Videl — ST/STE-compatible and Falcon standard modes" },
{ "id": "videl_highcolour","fram_addr": "0x2011", "type": "bool",
"status": "experimental", "default": false,
"requires": ["machine_type:5", "videl_standard:true"],
"description": "Videl 16-bit high-colour mode — in progress" },
{ "id": "videl_palette", "fram_addr": "0x2012", "type": "bool",
"status": "experimental", "default": false,
"requires": ["machine_type:5", "videl_standard:true"],
"description": "Falcon 262144-colour palette — in progress" },
{ "id": "dsp56001", "fram_addr": "0x2020", "type": "bool",
"status": "experimental", "default": false,
"requires": ["machine_type:5"],
"description": "DSP 56001 — experimental; most DSP-dependent software will not yet run correctly" },
{ "id": "crossbar", "fram_addr": "0x2030", "type": "bool",
"status": "experimental", "default": false,
"requires": ["machine_type:5"],
"description": "Crossbar audio routing matrix — experimental" },
{ "id": "falcon_ide", "fram_addr": "0x2050", "type": "bool",
"status": "beta", "default": true,
"requires": ["machine_type:5"],
"description": "Falcon native IDE interface" },
{ "id": "cpu_speed", "fram_addr": "0x1010", "type": "enum",
"status": "stable",
"values": [
{ "value": 0, "label": "Authentic" },
{ "value": 1, "label": "16 MHz" },
{ "value": 2, "label": "Turbo" }
],
"default": 0 },
{ "id": "tt_ram", "fram_addr": "0x2041", "type": "enum",
"status": "stable",
"requires": ["machine_type:4,5"],
"values": [
{ "value": 0, "label": "None" },
{ "value": 1, "label": "256 MB" },
{ "value": 2, "label": "1024 MB" }
],
"default": 1,
"description": "32-bit TT-RAM via FireStorm DDR3 and 68030 MMU" }
],
"presets": [
{ "id": "st_authentic", "label": "ST — Authentic",
"components": { "machine_type": 0, "cpu_speed": 0 } },
{ "id": "ste_standard", "label": "STe — Standard",
"components": { "machine_type": 2, "cpu_speed": 0, "blitter": true,
"ste_palette": true, "ste_dma_sound": true } },
{ "id": "mega_ste", "label": "Mega STe — 16 MHz",
"components": { "machine_type": 3, "cpu_speed": 1, "blitter": true,
"ste_palette": true, "ste_dma_sound": true } },
{ "id": "tt", "label": "TT",
"components": { "machine_type": 4, "tt_shifter": true,
"tt_scsi": true, "tt_ram": 1 } },
{ "id": "falcon_stable", "label": "Falcon — Stable",
"components": { "machine_type": 5, "videl_standard": true,
"dsp56001": false, "crossbar": false,
"falcon_ide": true, "tt_ram": 1 } },
{ "id": "falcon_full", "label": "Falcon — Full (experimental)",
"components": { "machine_type": 5, "videl_standard": true,
"videl_highcolour": true, "videl_palette": true,
"dsp56001": true, "crossbar": true,
"falcon_ide": true, "tt_ram": 2 } }
]
}Ant64 Atari Extended additions available in enhanced mode — applied consistently across all four machine variants:
The enhancements are designed around a single principle: where the Falcon already has superior hardware, its register interface becomes the standard for the whole range. ST and STe software targeting enhanced mode writes to Falcon-compatible registers; Falcon software works natively. One enhanced codebase runs on all four machines.
Hardware sprites (ST / STe / TT / Falcon — all variants) — none of the four machines has proper hardware sprites natively (the STe's 16 "blitter sprites" are limited; Videl has no sprite layer). A hardware sprite engine is synthesised in spare LUTs and exposed at a consistent new register address across all four machine types. A game written using the sprite registers runs identically on ST, STe, TT, and Falcon modes — the only genuinely new register interface in the enhanced set.
Blitter speed (all variants) — the enhanced blitter runs at 2× with results identical to the original, halving cycle time for blitter-intensive code. Applies uniformly across the full range; the blitter register interface is unchanged.
Extended audio (ST / STe / TT — via Falcon Crossbar registers) — rather than inventing a new 16-bit audio extension, the Falcon's Crossbar audio routing matrix is the reference. ST, STe, and TT enhanced mode exposes Crossbar registers at their standard Falcon addresses. Software targeting enhanced audio writes Falcon Crossbar registers; Falcon software works natively. The same audio code runs on all four machines.
Extended palette (ST / STe / TT — via Falcon Videl palette registers) — the Falcon's Videl already provides 65,536 colours in 16-bit mode. ST, STe, and TT enhanced mode exposes a compatible subset of Videl's palette registers at the standard Falcon addresses rather than an invented 24-bit scheme. Again, palette code written for enhanced ST mode is Falcon-compatible by definition.
The result: enhanced software written once targets all four Atari machines. ST and STe get the hardware they always lacked; TT and Falcon retain full compatibility with anything written to the enhanced register model.
DSP 56001 bus contention (Falcon) — in the original Falcon the DSP 56001 and 68030 compete for the same memory bus. On the Ant64 both run as parallel hardware blocks on independent SRAM buses with no contention. The DSP maps onto FireStorm's audio DSP pipeline, allowing the Falcon's Crossbar audio routing and effects chain to be extended with FireStorm's own reverb, EQ, and spatial processing running simultaneously with original DSP code.
Commodore 64 Cartridge
Target systems: Commodore 64, C64C, SX-64, Commodore 128
FPGA core: MiSTer C64 core Source: github.com/MiSTer-devel/C64_MiSTer Licence: GPL v2 CPU mode: Softcore (MOS 6510 in FPGA; SID chip as dedicated audio core)
The C64 core implements: the MOS 6510 CPU (as a soft-core), the VIC-II video chip (the C64's sprite and bitmap graphics hardware), the two 6526 CIA chips, and — critically — the MOS 6581/8580 SID sound chip.
The SID is one of the most sonically distinctive chips in computing history. The MiSTer SID implementation uses the reSID algorithm ported to FPGA, producing cycle-accurate SID output including the filter behaviour that gives SID music its characteristic warmth. This runs in FPGA fabric directly.
OS folder contents:
c64.rom— C64 KERNAL + BASIC + Character ROM (user must supply or use free replacements)JiffyDOS.rom— JiffyDOS enhanced DOS (user must supply if desired)
ROMS folder: Disk images (.d64, .g64), tape images (.tap), cartridge images (.crt).
C128 mode — the core optionally supports Commodore 128 mode with the 8502 CPU running at 2MHz and the VDC 80-column chip. Requires C128 ROM images.
REU (RAM Expansion Unit) — a 16MB REU is synthesised in spare FPGA LUTs alongside the C64 core, present automatically without a physical cartridge. The REU draws from the FireStorm DDR3 pool shared with the rewind buffer. Demos and applications (GEOS, fast loaders) that target the REU benefit significantly; standard C64 software is unaffected.
65816 CPU upgrade — the 6510 softcore can be replaced with a W65C816S via the Advanced CPU component. The 65816 starts in 6502 emulation mode — all ROM and boot code runs identically — and software switches to native mode for 16-bit registers and a 24-bit address bus. Compatible with the SuperCPU interface and the MEGA65's GS4510 at the instruction set level.
Ant64 C64 / C128 Extended additions available in enhanced mode:
Stereo SID (C64 / C128) — a second SID synthesised in spare LUTs, addressable at the standard second-SID address ($D420 or $DE00). Many SID compositions were written for stereo SID hardware; the extended mode makes these play as intended. Not applicable in MEGA65 mode — quad-SID is already native.
SCPU-equivalent fast CPU (C64 / C128) — a 65816-compatible fast execution unit providing a SuperCPU-equivalent fast mode. The cycle-accurate 6510 remains in the standard core and is unaffected. Not applicable in MEGA65 mode — the GS4510 already runs at up to 40.5 MHz natively.
Hardware sprites extended (C64 / C128) — the VIC-II's 8 sprites at 24×21 pixels become 64 sprites through extended sprite logic. The native 24×21 shape is preserved so existing C64 sprite artwork is compatible without modification. Not applicable in MEGA65 mode — VIC-IV provides far more capable display hardware.
RAM expansion (C64 / C128) — REU-compatible 1MB expansion from the FireStorm DDR3 pool, automatically available with no physical REU cartridge required (the 16MB REU described above is the larger option). Not applicable in MEGA65 mode — the GS4510's 28-bit address space provides access to far more memory natively.
MEGA65 / C65 mode — the Ant64 C64 cartridge adopts the MEGA65 register interface (VIC-IV video controller, GS4510 CPU with 28-bit address space at up to 40.5 MHz, quad-SID audio, DMAgic DMA). This is a complete platform in its own right — the officially specified but never-released Commodore 65, fully open source. MEGA65-aware software runs without modification; full C64 software runs in the standard mode. In MEGA65 mode, FireStorm DDR3 backs the full 28-bit address space. Source: github.com/MEGA65/mega65-core (GPL v3).
Atari 8-bit Cartridge
Target systems: Atari 400, 800, 800XL, 130XE, 5200
FPGA core: MiSTer Atari800 core Source: github.com/MiSTer-devel/Atari800_MiSTer Licence: GPL v3 CPU mode: Softcore (6502 in FPGA)
Implements the Atari 8-bit custom chips: POKEY (audio + keyboard + serial), ANTIC (display list coprocessor), GTIA (graphics/colour), and PIA. POKEY is the audio chip — its 4-channel sound with the characteristic high-frequency noise mode is implemented in FPGA fabric.
The Atari 8-bit platform contains "Passionately" by Gary Gilbertson (1983), referenced in the Ant64 demo works section. Running this on the Atari 8-bit personality with the original POKEY implementation is the authentic reference for the proposed "Heritage" demo work.
OS folder: Atari OS ROM images (800, XL, XE variants). AtariOS is copyrighted; free alternatives (AltirraOS) are included.
ROMS folder: Disk images (.atr, .atx), cassette images (.cas), ROM cartridge images (.rom, .car).
65816 CPU upgrade — the 6502C softcore can be replaced with a W65C816S via the Advanced CPU component. Boots in 6502 emulation mode; existing Atari 8-bit software is unaffected.
Ant64 Atari 8-bit Extended additions available in enhanced mode:
Dual POKEY stereo — a second POKEY synthesised in spare LUTs at $D210, compatible with the standard stereo POKEY community address mapping. Hundreds of stereo POKEY music compositions in the Atari demo scene play correctly with this enabled.
VBXE (VideoBlaster Extended) — an open source FPGA-based video expansion that adds hardware sprites, a chunky pixel mode without colour clash, and extended palette to the GTIA/ANTIC video system. The MiSTer Atari800 core includes VBXE as a supported option; the Ant64 synthesises it in spare LUTs. Software written for VBXE detects the registers at the standard PBI address range and uses them without modification. Status: beta.
BBC Micro Cartridge
Target systems: BBC Model B, Model B+, BBC Master 128, Electron
FPGA core: MiSTer BBC Micro core Source: github.com/MiSTer-devel/BBCMicro_MiSTer Licence: GPL v3 CPU mode: Softcore (6502 / 65C12 in FPGA)
Implements the BBC Micro's custom video ULA (Vidproc), the 6845 CRTC, the SN76489 sound chip (on later models), the 6522 VIA chips, the Tube interface (for second processor support), and the 1770 floppy controller.
The BBC Micro's Mode 7 teletext display — a character mode using a dedicated SAA5050 teletext character generator chip — is implemented in the core. The BBC Micro's remarkably capable graphics modes (Mode 0 at 640×256 with 2 colours through to Mode 2 at 160×256 with 16 colours) are all supported.
OS folder: BBC Micro OS and BASIC ROMs. Acorn's ROMs have been released for free distribution; they are included on the cartridge.
ROMS folder: Disk images (.ssd, .dsd, .img), cassette images (.uef, .csw), ROM images for sideways ROM slots.
65816 CPU upgrade — the 6502/65C12 softcore can be replaced with a W65C816S via the Advanced CPU component. Boots in 6502 emulation mode; existing BBC software is unaffected. The fast Tube co-processor option can also run a 65C816 as the second processor.
Ant64 BBC Extended additions available in enhanced mode:
Hardware sprites — 32-sprite hardware layer synthesised in spare LUTs, fully integrated with the 6845 CRTC timing. The BBC Micro had no hardware sprites at all.
Mode X — a 320×256 256-colour video mode beyond the original Modes 0–7, via spare video logic LUTs.
SN76489 stereo — 3-chip stereo SN76489 in enhanced mode, adding left, right, and centre channels from three parallel implementations.
Tube co-processor — the BBC's Tube interface is synthesised in spare LUTs alongside the co-processor CPU core, running at full FPGA speed rather than the original 2MHz clock limit. The host 6502 communicates via standard Tube register addresses; all OS-call-based software runs at whatever speed the co-processor allows:
{ "id": "tube_copro", "type": "enum", "values": [
{ "value": 0, "label": "None" },
{ "value": 1, "label": "6502 (3 MHz authentic)" },
{ "value": 2, "label": "6502 (fast — no speed limit)" },
{ "value": 3, "label": "65C816 (fast)" },
{ "value": 4, "label": "Z80 (6 MHz authentic — CP/M)" },
{ "value": 5, "label": "ARM2 (fast)" }
]}The Z80 option enables CP/M via the Z80 second processor protocol. The ARM2 option mirrors the original Acorn ARM Evaluation System. The fast 6502 and 65C816 options provide PiTubeDirect-equivalent high-speed second processor in FPGA fabric. Software that uses OS calls for all I/O — BBC BASIC does, as does properly-written machine code — runs at whatever speed the co-processor allows.
MSX Cartridge
Target systems: MSX1, MSX2, MSX2+
FPGA core: MiSTer MSX core Source: github.com/MiSTer-devel/MSX_MiSTer Licence: GPL v3 CPU mode: Softcore (T80 Z80 in FPGA)
The MSX standard was a common hardware specification across multiple Japanese manufacturers. The core implements the TMS9918/V9938/V9958 VDP (Video Display Processor), the AY-3-8910 PSG, and the MSX-MUSIC (OPL1) FM synthesis chip present in MSX2 configurations.
OS folder: MSX BIOS and BASIC ROMs for MSX1 and MSX2. Included via the MSX Resource Center's open BIOS distribution.
ROMS folder: ROM cartridge images (.rom), disk images (.dsk), tape images (.cas).
The MSX platform is the home of the original Gradius/Nemesis games — directly relevant to the "Vic Raider" design reference.
Ant64 MSX Extended additions available in enhanced mode:
V9990 GPU — the V9990 was a Yamaha graphics chip designed as an MSX VDP successor but rarely used due to cost. The enhanced mode synthesises the V9990's 256-colour bitmap modes, hardware sprites, and pattern generator in spare LUTs. V9990-aware software accesses the 256×212 256-colour mode without modification.
OPL4 audio — the MSX had OPL1 (MSX-Music) or OPL2 (MSX-Audio) FM synthesis. The enhanced mode synthesises OPL4 (YMF278B) in spare LUTs: the FM synthesis of OPL2 plus a 24-voice PCM sample channel, giving MSX audio comparable to early PC sound cards.
OCM-PLD / MSX++ — the Ant64 MSX personality adopts the OCM-PLD switched I/O port scheme ($40–$4F) as its compatibility target: turbo CPU speeds, PSG2 (second AY-3-8910 for stereo audio), OPL3 FM synthesis, and MegaRAM expansion up to 4096KB. Software written for any OCM-compatible MSX++ machine runs without modification.
Amstrad CPC Cartridge
Target systems: CPC 464, CPC 664, CPC 6128, Plus/GX4000
FPGA core: MiSTer Amstrad CPC core Source: github.com/MiSTer-devel/Amstrad_MiSTer Licence: GPL v3 CPU mode: Softcore (T80 Z80 in FPGA)
Implements the CPC's Gate Array (the primary custom chip handling video modes and memory banking), the AY-3-8912 sound chip, and the 8255 PPI. The CPC's distinctive 27-colour palette at up to 160×200 resolution is a notable feature of the platform.
OS folder: CPC ROM images (AMSDOS, BASIC). Amstrad has permitted free non-commercial distribution; ROMs included.
ROMS folder: Disk images (.dsk), tape images (.cdt), snapshot files (.sna).
Z80N / enhanced CPU — the CPC's Z80 softcore supports Z80N extended instructions via the Advanced CPU component, using the same FRAM register switching mechanism. Existing CPC software is unaffected; new software targeting the extended instruction set gets hardware multiply, block copy improvements, and the full Z80N opcode set.
Apple II Cartridge
Target systems: Apple II, II+, IIe, IIc, IIgs (IIgs partial)
FPGA core: MiSTer Apple II core Source: github.com/MiSTer-devel/Apple-II_MiSTer Licence: GPL v3 CPU mode: Softcore (6502 / 65C02 / 65C816 in FPGA fabric — see personality_cpu)
Implements the Apple II's video circuitry (text, lores, hires, double-hires), the Disk II floppy interface, and the speaker. The IIe variant adds 128KB extended memory and the 65C02 CPU.
OS folder: Apple II ROM images. Apple's older ROMs are in the public domain; they are included. IIgs ROMs require user supply.
ROMS folder: Disk images (.do, .po, .woz, .2mg), nibble images (.nib).
65816 CPU upgrade — the 6502/65C02 softcore can be replaced with a W65C816S via the Advanced CPU component — the same upgrade path the Apple IIGS used. Boots in 6502 emulation mode; existing Apple II software is unaffected.
PC / DOS Cartridge
Target systems: IBM PC, PC/XT, PC/AT, 386, 486 (DOS era)
FPGA core: ao486 (MiSTer) Source: github.com/MiSTer-devel/ao486_MiSTer Licence: GPL v2 CPU mode: Softcore (ao486 — full x86 486 core in FPGA fabric — see personality_cpu)
The ao486 core implements the complete 486 PC architecture in FPGA fabric: the 486 CPU, VGA graphics controller, OPL2/OPL3 FM synthesis (Sound Blaster compatible), UART, and system board logic — all as synthesised hardware. The personality_cpu speed multiplier table lists the 486 at 20–40× original speed depending on clock and cache behaviour, reflecting the combination of zero-wait-state SRAM and the pipelined softcore replacing original DRAM with 2–4 wait states.
OS folder: BIOS images (free SeaBIOS included), FreeDOS (fully free, included), MS-DOS 6.22 images (user must supply — commercial software).
ROMS folder: Hard disk images (.img, .vhd), floppy images (.img), CD-ROM images (.iso, .cue+.bin) via the virtual CD-ROM interface.
OPL audio — the ao486 core's OPL2/OPL3 implementation produces authentic FM synthesis audio for Sound Blaster-compatible titles. This runs in FPGA fabric. The output routes through FireStorm's audio DSP chain, with the optional environmental DSP available as an OSD toggle.
Sound Blaster 16 / Gravis UltraSound — the ao486 personality implements a Sound Blaster 16 (with OPL3) in FPGA fabric alongside the 486 core, and optionally a Gravis UltraSound. SB16 digital audio output routes through FireStorm's audio DSP to the main speakers. The GUS uses the FireStorm DDR3 pool for its sample memory — the full 16MB GUS patch set is available, producing high-quality MIDI audio from DOS games that supported the GUS.
Homebrew Cartridge
Target systems: Agon Light, RC2014, LM80C Color Computer
Licence: Open source hardware and firmware throughout CPU modes: eZ80 (Agon), Z80 (RC2014, LM80C) Ant64S: All three fit comfortably within the 60K fabric
Beyond historical machines, a generation of modern homebrew computers has emerged with their own software ecosystems and communities. These are not emulators or replicas — they are new computers designed from scratch with retro aesthetics and 8-bit philosophies but built on modern silicon. The Ant64 personality gives them the FireStorm display pipeline, the DeMon debug bridge, the rewind system, and Colony Connection networking that no original hardware version has. For developers building software for these machines, the Ant64 personality is the highest-performance reference platform available.
Agon Light — eZ80 + ESP32
Hardware designed by: Bernardo Kastrup (The Byte Attic) Firmware by: Dean Belfield, Jeroen Venema, and contributors Source: github.com/TheByteAttic/AgonLight Firmware: github.com/breakintoprogram/agon-mos Licence: Open source hardware (OSHWA certified); firmware zlib licence Variants: Agon Light, AgonLight2 (Olimex redesign), AgonOrigins, Console8
The Agon is a modern fully open-source eZ80-based microcomputer — not an emulator, not a clone. It is a standalone computer with VGA output, PS/2 keyboard, and SD card storage running BBC BASIC as its primary language. The eZ80F92 CPU is a Zilog product fully backwards compatible with the Z80 but adding a 24-bit address space (16MB), 24-bit registers, and a switchable ADL (Address Data Long) mode where all operations and addresses are natively 24-bit. It runs at 18.432 MHz on the Agon hardware.
The firmware has two layers: MOS (Machine Operating System, a DOS-like shell running on the eZ80) and VDP (Visual Display Processor, running on the co-processor ESP32 that handles video, audio, and keyboard). The two communicate over a high-speed UART. BBC BASIC for Agon is a port of R.T. Russell's Z80 BBC BASIC, extended to use eZ80 ADL mode.
The Agon has an active and growing software community writing games, demos, and utilities for it. It also runs CP/M and has an MSX personality.
Ant64 Agon personality — the eZ80 softcore running at full FPGA speed. The ESP32 VDP co-processor role is replaced by the FireStorm display pipeline: the VDP firmware's VDU command API is reimplemented as native FireStorm blitter operations, giving Agon software the FireStorm's sprite hardware, copper, and bloom effects with no software changes. The MOS API is preserved exactly — existing Agon software runs without modification.
{ "id": "cpu_speed", "type": "enum",
"values": [ { "value": 0, "label": "18.432 MHz (authentic)" },
{ "value": 1, "label": "Fast" } ],
"default": 0 },
{ "id": "adl_mode_default", "type": "enum",
"values": [ { "value": 0, "label": "Z80 (64K segments, authentic)" },
{ "value": 1, "label": "ADL (24-bit, full 16MB)" } ],
"default": 0,
"description": "eZ80 boot mode — software can switch at runtime regardless" }RC2014 — Modular Z80
Source: rc2014.co.uk — open hardware Licence: Open source hardware, MIT firmware Status: Active community; the most active Z80 retrocomputing community
The RC2014 is a modular Z80 computer built around a simple backplane. It originally ran Microsoft BASIC from 8K ROM with 32K RAM at 7.3728 MHz, but the modular design has spawned an extensive ecosystem: pageable ROM, 64K RAM, compact flash storage, serial terminals, video cards, and more. It runs CP/M natively. The Ant64 personality's primary value here is access to the CP/M ecosystem — including the vast archive of CP/M business software, languages (Turbo Pascal, WordStar, dBASE), and the RC2014 community's own growing software library.
LM80C Color Computer — Z80 + TMS9918 + AY
Source: github.com/leomil72/LM80C Designed by: Leonardo Miliani (since 2019) Licence: Open source hardware and software Status: Active; complete standalone home computer with its own BASIC dialect
The LM80C is an 8-bit home computer designed from scratch around a Z80 CPU, a TMS9918A VDP (the same chip used in the MSX, ColecoVision, and TI-99/4A), and an AY-3-8910 sound chip, with its own BASIC dialect derived from Nascom BASIC. Its hardware is directly compatible with the MiSTer MSX core's video and audio implementations — the Ant64 MSX cartridge already synthesises both chips in fabric, and the LM80C personality reuses that hardware with the LM80C-specific memory map and I/O layout.
OS folder: MOS firmware for Agon; firmware ROMs for RC2014 and LM80C (all freely distributable; included on cartridge).
ROMS folder: Agon software images, RC2014 disk images (.img, .dsk), LM80C ROM and disk images.
Console Cartridges
Nintendo Cartridge
Target systems: NES, Famicom, Famicom Disk System, SNES, Super Famicom, Super Game Boy
FPGA cores: MiSTer NES core + MiSTer SNES core Sources:
- github.com/MiSTer-devel/NES_MiSTer — GPL v2
- github.com/MiSTer-devel/SNES_MiSTer — GPL v2 CPU mode: Softcore (6502/2A03 for NES; 65C816 for SNES — same softcore, different mode) Ant64S: Supported — NES alone fits comfortably; combined NES+SNES fits within 60K
The NES and SNES are architecturally related enough to share a single combined bitstream. The SNES is in many ways a superset of the NES by deliberate design: the 65C816 runs in emulation mode as a 6502 (the same core the NES uses), the controller registers at $4016/$4017 were carried directly from NES to SNES unchanged, and the SNES PPU has NES-compatible background and sprite modes as a subset. The NES's RAM at $0000–$07FF and cartridge space at $8000–$FFFF both map cleanly into the SNES address space without conflict.
The combined NES+SNES bitstream costs approximately 28–30K LUTs chipset — NES (~8–10K) plus SNES (~20K) — well within the 138K fabric and fitting the Ant64S 60K budget too.
manifest.json machine type and component switching:
{ "id": "machine_type", "type": "enum", "values": [
{ "value": 0, "label": "NES / Famicom" },
{ "value": 1, "label": "Famicom Disk System" },
{ "value": 2, "label": "SNES / Super Famicom" },
{ "value": 3, "label": "Super Game Boy" }
]}
{ "id": "nes_mapper", "requires": ["machine_type:0,1"],
"description": "Cartridge mapper — auto-detected from ROM header" }
{ "id": "nes_apu", "requires": ["machine_type:0,1"],
"description": "2A03 APU (pulse, triangle, noise, DPCM)" }
{ "id": "fds_bios", "requires": ["machine_type:1"],
"description": "Famicom Disk System BIOS" }
{ "id": "spc700", "requires": ["machine_type:2,3"],
"description": "SPC700 audio processor + 8-channel Sony DSP" }
{ "id": "enhancement_chip", "requires": ["machine_type:2,3"],
"auto_detect": true,
"description": "SNES co-processor — auto-detected from ROM header" }
{ "id": "sgb_sm83", "requires": ["machine_type:3"],
"description": "Super Game Boy Sharp SM83 co-processor" }Components always present in both modes: the 65xx CPU softcore, the PPU (SNES PPU has NES-compatible modes as a subset), controller ports at $4016/$4017, and the memory controller/mapper. Switching between NES and SNES mode is a single FRAM register write — no bitstream reload, no loss of state.
NES mode implements the RP2C02 PPU, the 2A03 CPU with integrated APU (two square waves, triangle, noise, DPCM), and over 200 mapper types covering the vast majority of the NES library. The Famicom Disk System adds the disk BIOS and RAM adapter.
SNES mode implements the full Mode 0–7 graphics system including the Mode 7 affine transformation that inspired the Ant64's own hardware Mode 7 implementation, the SPC700 audio processor with eight Sony DSP channels, and all cartridge co-processors (Super FX, SA-1, DSP-1 through DSP-4, CX4, ST-018 ARM60, Super Game Boy) auto-detected from the ROM header. The full co-processor list is documented in personality_cpu.
The SNES core is the reference platform for the snesrev engine games (Zelda 3, Super Metroid, Super Mario World) in the games collection — run the originals on the SNES personality, then run the snesrev enhanced versions natively on AntOS.
OS folder: No OS ROM required for either mode.
ROMS folder: NES ROM images (.nes), Famicom Disk System images (.fds), SNES ROM images (.smc, .sfc, .fig).
Sega Mega Drive / Genesis Cartridge
Target systems: Mega Drive, Genesis, Mega CD (partial), 32X (partial)
FPGA core: MiSTer Genesis core Source: github.com/MiSTer-devel/Genesis_MiSTer Licence: GPL v2 CPU mode: Softcore (68000 main CPU + Z80 sound CPU in FPGA)
Implements the VDP (Video Display Processor — the Mega Drive's sprite and scrolling plane hardware), the YM2612 FM synthesis chip (6-operator FM, the characteristic Mega Drive sound), the SN76489 PSG, and both CPUs (68000 main + Z80 audio coprocessor) as soft-cores.
The YM2612 implementation produces authentic 6-operator FM synthesis audio — the same operator FM architecture used by the Ant64's own audio system. Running the Mega Drive personality and then switching to AntOS native audio is an interesting technical comparison.
OS folder: Mega Drive BIOS (region-specific). Included where freely redistributable.
ROMS folder: ROM images (.md, .gen, .bin), Mega CD disc images (.iso, .bin+.cue).
Sega Master System / Game Gear Cartridge
Target systems: Sega Master System, Mark III, Game Gear
FPGA core: MiSTer Master System core Source: github.com/MiSTer-devel/SMS_MiSTer Licence: GPL v2 CPU mode: Softcore (Z80 in FPGA)
Implements the VDP (TMS9918-derived), the SN76489 PSG, and the Z80 CPU soft-core. Lighter-weight than the Mega Drive core; fits comfortably with the overlay block within the GoWin 138k's LUT budget.
ROMS folder: ROM images (.sms, .gg).
GBA Cartridge
Target systems: Game Boy Advance
FPGA core: MiSTer GBA core Source: github.com/MiSTer-devel/GBA_MiSTer Licence: GPL v2 CPU mode: Softcore (ARM7TDMI in FPGA) Ant64S: Supported — fits within 60K fabric
Implements the GBA's ARM7TDMI CPU, the PPU (background layers, OBJ sprites, affine transformations — Mode 7-style scaling and rotation available natively), and the APU (two direct-sound DMA channels plus four legacy Game Boy channels). The GBA's ARM7TDMI is a genuine 32-bit RISC core, making this one of the more computationally capable softcores in the catalogue.
ROMS folder: GBA ROM images (.gba).
OS folder: No OS ROM required — the GBA BIOS is optional; a free replacement is included.
Atari Cartridge
Target systems: Atari 2600, Atari 7800
FPGA cores: MiSTer Atari 2600 core + MiSTer Atari 7800 core Sources:
- github.com/MiSTer-devel/Atari2600_MiSTer — GPL v2
- github.com/MiSTer-devel/Atari7800_MiSTer — GPL v2 CPU mode: Softcore (6507 / 6502C in FPGA) Ant64S: Supported — both machines are small; combined bitstream fits within 60K
The Atari 7800 was explicitly designed with full backward compatibility with the 2600 — Atari built a real TIA chip into the 7800 hardware for this purpose. In 2600 mode the 7800 disables its MARIA graphics chip entirely and routes all display and audio through TIA, exactly as the original 2600 does. The two machines are therefore the most natural combined cartridge in the catalogue: the 7800 already contains the 2600 as a hardware subset, and the FPGA simply mirrors that relationship.
The 7800 address space is a superset of the 2600's, with MARIA registers added at $0040–$007F and cartridge space extended. Switching from 7800 to 2600 mode disables MARIA and re-enables TIA's full control of the display — a single FRAM register write.
The combined 2600+7800 bitstream fits in approximately 10–14K LUTs chipset, making it by far the smallest console bitstream and leaving substantial room for enhanced modes.
manifest.json machine type and component switching:
{ "id": "machine_type", "type": "enum", "values": [
{ "value": 0, "label": "Atari 2600 / VCS" },
{ "value": 1, "label": "Atari 7800" }
]}
{ "id": "maria", "requires": ["machine_type:1"],
"description": "MARIA graphics chip — automatic in 7800 mode, disabled in 2600 mode" }
{ "id": "pokey", "requires": ["machine_type:1"],
"description": "POKEY audio chip — present in some 7800 cartridges alongside TIA" }
{ "id": "cpu_ext", "type": "enum",
"values": [
{ "value": 0, "label": "6507 / 6502C (authentic)" },
{ "value": 1, "label": "6502 (full 64KB, IRQ/NMI restored)" },
{ "value": 2, "label": "65816 (24-bit, 16-bit registers)" }
],
"default": 0,
"description": "CPU extension — see personality_cpu. Existing software unaffected." }In 7800 mode, some cartridges included a POKEY chip alongside TIA for enhanced audio — the FPGA synthesises this in spare LUTs and enables it automatically when the ROM header indicates its presence, exactly as with SNES co-processors.
The 6507 CPU extension (full 6502 address space, 65816 upgrade) is described in detail in the CPU Enhancements section.
65816 / Full 6502 Mode — Atari 2600
The Atari 2600 uses the 6507 — a cost-reduced 6502 with 13 address lines instead of 16, and with the IRQ and NMI interrupt lines removed. The address space is therefore 8KB (0x0000–0x1FFF) rather than the 6502's full 64KB. All 2600 software is written to fit within this constraint; the TIA chip's hardware-managed display list means the 6507 has very little CPU time per frame and the tight address space was never a practical limit for original software.
The 6507 and 6502 chips use the same underlying silicon layers and differ only in the final metallisation layer — the three missing address lines and the interrupt pins are simply not bonded out, not absent from the silicon. In the FPGA, restoring them costs nothing. Enabling full 6502 mode expands the address space to 64KB and restores IRQ and NMI. Existing 2600 software is unaffected: it only addresses within the 6507's original range and never generates interrupts.
There is some precedent for this idea in hobbyist hardware — enthusiasts have built 2600 modifications that physically replace the 6507 with a 6502 on the motherboard, and there have been homebrew cartridge designs that exploit the full address bus. A commercial cartridge-slot CPU upgrade for the 2600 does not appear to have been a real product; this may be something you are half-remembering or confusing with a different machine or project. The well-known Supercharger cartridge added 6KB of RAM but kept the original 6507. If a commercial CPU cartridge upgrade does exist, it was extremely obscure.
The 65816 upgrade takes this further, adding 16-bit registers and a 24-bit address bus (16MB). For a machine with the TIA's display hardware and the Ant64's FireStorm pipeline behind it, the 65816 turns the 2600 personality into a substantial programming platform. The original TIA sprite and playfield hardware remains available in the lower address range; the expanded address space above that is available to new software and to bank-switching schemes.
{
"id": "cpu_adv_2600",
"label": "CPU extension (Advanced)",
"fram_addr": "0x7080",
"type": "enum",
"status": "experimental",
"values": [
{ "value": 0, "label": "6507 (authentic — 13-bit addressing, no IRQ)" },
{ "value": 1, "label": "6502 (full 64KB address space, IRQ/NMI restored)" },
{ "value": 2, "label": "65816 (24-bit addressing, 16-bit registers)" }
],
"default": 0,
"description": "Restores the three address lines and interrupts masked off in the 6507 die. Existing 2600 software unaffected. 65816 boots in 6502 emulation mode."
}The 6502 mode is the most practically useful for new Ant64-specific 2600 software: the full address space is available with no compatibility risk, and the IRQ line is restored for timer-driven audio and game logic. The 65816 mode is for software that explicitly targets the extended instruction set.
OS folder: No OS ROM required for either mode.
ROMS folder: NES ROM images (.nes), Famicom Disk System images (.fds), SNES ROM images (.smc, .sfc, .fig).
OS folder: No OS ROM required for either mode. The 7800 BIOS is optional — most cartridges work without it, and a free replacement is included.
ROMS folder: 2600 ROM images (.a26, .bin), 7800 ROM images (.a78, .bin).
The Arcade Cartridge
All arcade machine simulations on a single cartridge.
The Arcade Cartridge differs from the home computer and console cartridges in
one important respect: it contains multiple FPGA bitstreams rather than one.
Each arcade system is a separate .rbf file in the FPGA/ directory. The
OSD's cartridge menu presents the list of available arcade cores; selecting
one causes DeMon to reprogram FireStorm with that core's bitstream.
/
├── FPGA/
│ ├── manifest.json ← Lists all available cores
│ ├── cps1.rbf ← Capcom CPS1 (Street Fighter II era)
│ ├── cps2.rbf ← Capcom CPS2 (Super Street Fighter II Turbo era)
│ ├── neogeo.rbf ← SNK Neo Geo MVS
│ ├── jt_gng.rbf ← Jotego Ghosts 'n Goblins (jt_gng, GPL v3)
│ ├── jt_1943.rbf ← Jotego 1943 (Capcom)
│ ├── jt_contra.rbf ← Jotego Contra
│ ├── jt_tora.rbf ← Jotego Tiger Road
│ ├── jtcps15.rbf ← Jotego CPS 1.5
│ ├── taito_f3.rbf ← Taito F3 system
│ ├── midway_cpa.rbf ← Midway CPA (Mortal Kombat era)
│ ├── sega_system16.rbf ← Sega System 16 (OutRun, Shinobi, Golden Axe)
│ ├── sega_system18.rbf ← Sega System 18 (Blades of Steel era)
│ ├── namco_system1.rbf ← Namco System 1 (Splatterhouse)
│ ├── irem_m72.rbf ← Irem M72 (R-Type, Image Fight)
│ └── ...
├── ROMS/
│ ├── cps1/ ← CPS1 ROM sets (user must supply)
│ ├── cps2/ ← CPS2 ROM sets (user must supply)
│ ├── neogeo/ ← Neo Geo ROM sets (user must supply)
│ ├── jt_gng/ ← Ghosts 'n Goblins ROM set (user must supply)
│ └── ...
└── ANT64/
└── arcade_menu.lua ← OSD arcade system selectorROM legal status: Arcade ROM sets are copyrighted by their original
publishers. The user must supply ROM sets from legally owned sources. The
FPGA cores themselves are open source (GPL). The ROMS/ directory on the
cartridge's microSD is pre-structured with the correct folder layout;
the user populates it.
Jotego cores — Jose Tejada's jotego project (github.com/jotego) is a collection of high-accuracy arcade system FPGA implementations, all released under GPL v3. The Ghosts 'n Goblins core (jt_gng) is directly relevant to the "The Long Dark" design reference. The full jotego suite covers dozens of Capcom, Konami, Irem, Taito, and Sega arcade systems.
Sega System 16 — directly relevant: the Cannonball OutRun engine runs on the System 16 hardware simulation. The arcade System 16 personality runs the original OutRun arcade ROM set on the hardware simulation of the original Sega System 16 PCB — the machine Cannonball was reversed from.
Core switching — when a new arcade core is selected from the OSD, DeMon
reprograms FireStorm with the new .rbf in approximately 200ms. The user
selects the ROM set from the new core's ROMS/ subfolder. Switching between
arcade systems is a 200ms reprogram plus a few seconds for ROM loading.
JAMMA input mapping — jog dials and buttons map to JAMMA arcade input conventions. Two-player arcade games with joystick inputs map to the Ant64's eight jog dials and button array. The mapping is configurable per core via the OSD.
ROM and OS Licensing
The FPGA cores on all personality cartridges are open source hardware descriptions (Verilog/VHDL, GPL-licensed) ported to the GoWin GW5AT-138k. The cores themselves have no licensing cost.
The OS images and ROM images are a separate matter:
Freely distributable (included on cartridge):
- AROS (Amiga Kickstart replacement) — APL v1.1
- EmuTOS (Atari ST TOS replacement) — GPL v2
- FreeDOS — GPL, various components
- SeaBIOS (PC BIOS replacement) — LGPL v3
- AltirraOS (Atari 8-bit OS replacement) — free for personal use
- BBC Micro OS ROMs — Acorn free distribution permission
- MSX BIOS — MSX Resource Center open distribution
- Apple II ROMs (Apple II, II+) — public domain
- Agon MOS firmware — zlib licence
- RC2014 / LM80C firmware — MIT / open source
- NES / SNES: no OS ROM required
- Atari 2600 / 7800: no OS ROM required (7800 BIOS optional; free replacement included)
- Sega Mega Drive: BIOS included where freely redistributable
- Sega Master System / Game Gear: no OS ROM required
- GBA: no OS ROM required
User must supply:
- Amiga Kickstart ROMs (copyrighted by Amiga/Cloanto — purchase via AmigaForever)
- Atari ST genuine TOS ROMs (copyrighted by Atari/Infogrames)
- C64 KERNAL/BASIC ROMs (copyrighted by Commodore/various)
- MS-DOS (copyrighted by Microsoft — purchase separately)
- All arcade ROM sets (copyrighted by original publishers)
- Apple IIgs ROMs (copyrighted by Apple)
The cartridge microSD's OS/ directory is pre-structured with the correct
filenames and a README.txt explaining which files to add and where to
obtain them legally.
Debug and Development in Personality Mode
The SG2000 big core (C906, 1GHz) is not used for CPU emulation — the target CPU runs in FPGA fabric. The big core is instead dedicated to an optional debug and development application that, when loaded, has complete read/write access to the running softcore via the Personality Interface Block's QSPI FRAM window: every CPU register, every byte of system RAM, every custom chipset register, all mapped into the C906's address space as ordinary memory.
This is hardware debugging at full hardware speed. The softcore runs at its optimised rate; the debug application observes and controls it through the same FRAM interface used by DeMon and AntOS for every other inter-subsystem communication on the Ant64.
Rewind
The player can run time backwards as well as forwards — scrubbing through the machine's execution history in either direction at any speed, from single-step to fast-rewind. The full detail is in personality_cpu; the mechanism is summarised here.
XOR delta ring buffer
The Personality Interface Block's rewind capture block records CPU register changes and RAM writes into a ring buffer in FireStorm DDR3 as the machine executes. Each entry stores an XOR delta — old value XOR'd with new value — packaged into a bitmask-compressed delta frame: only registers that actually changed are stored, with a bitmask indicating which. The read-before-write for RAM deltas happens in the capture block's own independent pipeline and adds no stall to the CPU.
XOR is self-inverse, so the same stored entry applies equally for undo and redo — directionality comes entirely from which way the ring buffer pointer moves. The pointer position is the current point in time.
Ring buffer depth
The ring buffer occupies a configurable allocation of FireStorm DDR3 — up to ~2 GB on the Ant64C, 1 GB on the Ant64. The depth depends on the CPU and its activity rate:
| CPU | Compressed rate | Ant64 (1 GB) | Ant64C (~2 GB) |
|---|---|---|---|
| 6502 @ 1 MHz | ~1.1 MB/s | ~15 minutes | ~29 minutes |
| Z80 @ 3.5 MHz | ~3.5 MB/s | ~5 minutes | ~9.5 minutes |
| 68000 @ 7.16 MHz | ~28 MB/s | ~36 seconds | ~72 seconds |
The DDR3 pool is shared between the rewind buffer and expanded system RAM available to the emulated machine — a user-configurable split. A game-focused personality defaults to maximum rewind depth; a development personality may default to maximum expanded RAM. See personality_cpu for the full tradeoff table.
Jog dial time scrubbing
DeMon has a dedicated jog dial used for system supervision and debug tasks — separate from the 8 jog dials on Pulse that control sequencer and MIDI parameters. In personality debug mode this dial becomes a physical time scrub control, with no PC or debug application window required:
- Rotate clockwise — advance time; faster = higher speed
- Rotate anticlockwise — rewind; faster = faster rewind
- Push — pause / resume
- Push and hold + rotate — single-step in either direction, one instruction per detent
- Fast spin — jumps checkpoint-to-checkpoint for coarse timeline navigation
DeMon translates jog dial events into FRAM register writes to the speed_ratio
register — the same register the debug application uses. The machine's timeline
is navigable physically with one hand on the dial.
What rewind restores
The capture block records CPU registers, RAM writes, and chipset register writes — the complete internal state of the emulated machine. Rewinding fully restores the CPU, all RAM, and all chipset state including display registers, audio parameters, DMA pointers, and sprite tables. The display and audio output resettles to match the restored state within one frame.
The only state that cannot be reversed is external I/O — signals that left the FPGA into the real world: MIDI output to external hardware, serial data, disk writes to physical media. For the overwhelming majority of debug and game use cases this is irrelevant.
Snapshot to save state
A save state can be taken at any point in the timeline — the current CPU and
RAM state written to SAVES/ on the cartridge microSD with a timestamp.
Loading a save state seeds the ring buffer from that point, giving the full
rewind depth from the save state's machine time.
CPU Debugger
The C906 debug application exposes a complete machine-code debugger via the ImGui overlay layer — the equivalent of a logic analyser and in-circuit emulator connected to the original machine simultaneously. The softcore's halt line is driven via the Interface Block; when halted, the C906 reads and writes registers and memory freely through the FRAM window.
The debugger is activated from the OSD. The target machine halts; the debugger overlay appears. The target machine's display remains visible behind the debugger panels.
Disassembly view
The current PC is highlighted in a scrollable disassembly of the target machine's memory at the current address. Instructions disassemble in the target CPU's native mnemonics: 68000 assembly for Amiga/Atari ST, 6502 assembly for C64/BBC/NES, Z80 assembly for Spectrum/MSX/CPC.
The disassembly view is live — when the machine is running at reduced speed
or single-stepping, the current instruction highlights in real time. Labels
from the cartridge's optional symbol file (ROMS/[game].sym) overlay the
raw addresses — if the user has a symbol file for the running software, the
disassembly shows function names and variable names.
Register panel
All CPU registers displayed and editable. For a 68000: D0–D7, A0–A7, PC, SR (with individual flag bits), USP, SSP. Click any register value to edit it — type a new hex value and it takes effect on the next step. Changing a register mid-execution is the most direct form of cheat implementation: set D0 to 99 for lives, set an address value for infinite energy.
Memory panel
A hex editor over the target machine's full address space. Scroll to any address; values update in real time during slow-step execution. The memory panel shows:
- RAM contents
- ROM contents (read-only, but visible)
- Custom chip register space (live hardware register values from the FPGA fabric via the DeMon bridge — Amiga custom chip registers, C64 VIC-II registers, etc.)
- I/O space (CIA, PIA, VIA registers — live values)
Any writable address can be edited directly. This is the mechanism for poke-style modifications — the Spectrum tradition of entering a POKE to disable a lives counter is available at this level for any machine.
Breakpoints
- Execution breakpoints: break when PC reaches a specified address. Up to 64 simultaneous breakpoints. Conditional breakpoints: break only when a register or memory value matches a condition (e.g. break at $1234 only when D0 = 0).
- Memory read/write watchpoints: break when any instruction reads or writes a specified address or address range. The watchpoint log records which instruction triggered it, from which PC, and the value read/written. Essential for tracking down where a lives counter is modified.
- Hardware register watchpoints: break when a specific custom chip register is written. For example: break when the Amiga's DMACON register is written, to trace DMA setup sequences.
Execution control
- Step: execute one instruction and pause
- Step over: execute a subroutine call as a single step (runs until return)
- Step out: run until the current subroutine returns
- Run to cursor: run until PC reaches the disassembly cursor position
- Slow run: execute at a fraction of normal speed (1%, 5%, 10%, 25%, 50%) with the display updating live — useful for watching memory change during a specific routine
- Run: resume full-speed execution
Call stack
The debug application maintains a reconstructed call stack — tracking JSR/BSR/CALL instructions and their return addresses via the instruction trace captured through the Interface Block. The call stack panel shows the current subroutine nesting depth and the address of each call frame. For machines with a clean calling convention (BBC BASIC's interpreter, Amiga's exec library calls), the stack is readable as a program flow trace.
Instruction trace log
A configurable circular buffer of the last N instructions executed (default: 10,000). Each entry: PC, instruction mnemonic, operand values, register state delta (which registers changed and to what). The trace log is the post-mortem tool — after a crash, scroll back through the instruction history to find the instruction that caused it.
Memory map visualiser
A colour-coded map of the target machine's address space showing: ROM regions, RAM regions, custom chip space, I/O space, currently-mapped pages (for bank-switched machines). For the Amiga: chip RAM, slow RAM, fast RAM, Kickstart ROM, custom chip space at $DFF000, CIA space. For the C64: the bank-switch state at any moment, showing which of the overlapping ROM/RAM regions are currently active. The map updates live during slow execution.
DMA trace
For machines with DMA (Amiga's Agnus, C64's VIC-II sprite DMA, SNES DMA): the DMA trace panel shows each DMA transfer as it occurs — source address, destination address, byte count, which channel. The Amiga's copper list can be decoded and displayed as a human-readable sequence of copper instructions. The Amiga's blitter operations are logged with source, destination, mask, and size parameters.
Symbol file support
If a .sym file exists in ROMS/ matching the current ROM/disk image name,
the debugger loads it. Symbol files map addresses to labels. This is the
mechanism that makes the debugger useful for development work on the target
machine — writing new software for the personality machine, on the Ant64,
with a full source-level debugger available.
The symbol file format is compatible with the common formats used by period assemblers and modern cross-assemblers: vasm, ca65, pasmo, and WinUAE's built-in debugger format.
CPU Speed Control
Speed control is available from the OSD at any time without interrupting the running machine. The full throttle mechanism — fixed-point cycle budget accumulator, decoupled vs coupled speed modes, available speed levels from authentic to turbo and including rewind, and the speed multiplier table for every supported platform — is documented in personality_cpu.
Per-machine notes
- Amiga: OS-based software is timing-insensitive. Coupled 4× is widely compatible. Demo code using copper timing is sensitive to chip clock rate.
- C64: many games use raster timing for effects. Decoupled mode breaks them.
- Atari ST: OS-based software is speed-insensitive. Blitter-heavy code benefits most from speed increase.
CPU and Architecture Enhancements
Because the CPU is synthesised logic rather than a fixed chip, its instruction set and behaviour can be extended at the HDL level. The full detail — Z80 dialects (standard / Z80N / eZ80), 68000 ISA extensions (68010 loop mode, full 68020 instruction set), 65816 upgrade for all 6502-based machines, SNES cartridge co-processors (Super FX, SA-1, ST-018 ARM60, and others), BBC Tube co-processor, C64 MEGA65 / GS4510 mode, MSX OCM-PLD enhancements, Dragon/CoCo GIME and HD6309 modes — is documented in personality_cpu.
One mechanism worth noting here: the C906 debug application can register TRAP #N handlers — a TRAP in the running software invokes the C906 handler via the FRAM interrupt mechanism, which executes a fast operation (decompression, file access, network) and returns results in softcore registers. The running software has no knowledge it is in a managed environment. This is the mechanism behind fast loading and network access available to software on any personality.
Cheat and Modification System
The combination of the debug application's memory search, the register editor, and the watchpoint system produces a complete cheat-finding and -applying environment.
Memory scanner
Search the entire address space for values matching a criterion. The classic cheat-finding workflow:
- Start with N lives. Search for value N in memory. Results: many matches.
- Lose a life. N is now N-1. Search for value N-1 among previous results. Results: fewer matches.
- Repeat until one address remains. That is the lives counter address.
- Set a write watchpoint on that address. The next time lives decrease, the watchpoint fires and shows which instruction wrote the new value.
- The debugger shows the instruction address. Set that address to NOP (no operation) to prevent the decrement — infinite lives.
The memory scanner panel is a persistent search tool: enter a value, mark results, update after a game event, refine. The workflow above takes 2–3 minutes for a well-behaved game.
Cheat database
A community-editable cheat database in the ROMS/ folder: cheats.json
maps ROM filenames to known cheat addresses and values. If the currently
running software is in the database, the OSD's cheat panel shows a list of
named cheats (Infinite Lives, All Weapons, Skip Level) that can be toggled.
Toggling a cheat applies the specified memory write each frame, overriding
the game's own value.
The cheat database file format is simple JSON; users can add their own entries and share them.
Save State System
Save states (distinct from rewind snapshots — these are permanent, named,
user-initiated) capture the complete machine state to SAVES/ on the
cartridge microSD.
A save state is a complete snapshot captured via the Personality Interface Block: CPU register state from the debug register bank, RAM contents via the FRAM window, custom chip registers, audio registers, disk controller state. For machines with battery-backed SRAM cartridges (SNES, Game Gear), the SRAM contents are included.
Save states are cross-session — a save state from one session can be loaded
in a future session. They are also useful as a distribution format for
sharing a specific machine state (a game at a specific point, a development
environment pre-configured) on the ROMS/ folder.
State slots
10 named save state slots per game image, plus unlimited named saves via the file browser. The OSD slot panel shows a thumbnail (the framebuffer at the moment of save) for each slot, making visual identification easy.
State rewind integration
Loading a save state seeds the rewind ring buffer from that point — the ring buffer pointer is positioned at the save state's machine time, giving the full rewind depth forward and backward from that starting point.
Porting MiSTer Cores to GoWin
The MiSTer cores target the Intel/Altera Cyclone V FPGA (the DE10-Nano development board). Porting to the GoWin GW5AT-138k requires:
Toolchain: Yosys synthesis + nextpnr-gowin place-and-route, with GHDL plugin for VHDL cores. The GoWin proprietary synthesis tool is also available as an alternative for cores where the open toolchain produces suboptimal results.
BRAM mapping: GoWin uses a different BRAM primitive structure than Intel. Cores using Intel-specific BRAM inference (altsyncram, altera_mf) require mapping to GoWin BSRAM primitives. This is the most common porting task.
PLL/clock generation: GoWin rPLL primitives replace Intel ALTPLL and ALTERA_PLL. Clock generation for cores requiring specific pixel clocks (PAL 8.8672MHz, NTSC 8.0MHz, etc.) uses the GoWin rPLL's fractional-N divider.
DSP blocks: GoWin DSP blocks (DSP18) have similar capabilities to Intel DSP primitives. Multiplier-heavy cores (some audio DSP, some video scaling) may require DSP block mapping adjustment.
Video output: MiSTer cores target the DE10-Nano's HDMI output via the HDMI daughter board. The Ant64's HDMI output path (through the overlay block) replaces this. The core's video output signals (RGB + sync) feed the overlay block's video mux rather than driving HDMI directly.
MiSTer HPS interface: MiSTer cores communicate with the HPS (ARM Linux system) via a specific bus interface for OSD, file loading, and settings. The Ant64 overlay block replaces the HPS with the DeMon bridge — DeMon presents the same interface to the core, fulfilling the OSD and file loading functions.
The porting effort per core ranges from a few days (Verilog-only cores with straightforward BRAM usage) to a few weeks (complex VHDL cores or cores with heavy vendor IP dependency). The MiSTer community's cores are actively maintained and well-documented; the port paths are understood.
Summary Table
| Cartridge | Target Systems | Core | CPU Mode | OS Status |
|---|---|---|---|---|
| Amiga | A500/600/1200/4000/CD32 | Minimig-AGA (GPL v3) | Softcore (68000–68060) | AROS free; Kickstart user-supplied |
| Atari 16/32-bit | ST/STe/TT/Falcon030 | Combined bitstream (GPL v3) | Softcore (68000+68030) | EmuTOS free; TOS user-supplied; Ant64 only |
| Commodore 64 | C64/C128 | MiSTer C64 (GPL v2) | Softcore (6510/65816) | Included replacements; KERNAL user-supplied |
| Atari 8-bit | 400/800/XL/XE/5200 | MiSTer Atari800 (GPL v3) | Softcore (6502/65816) | AltirraOS free; AtariOS user-supplied |
| BBC Micro | Model B/B+/Master/Electron | MiSTer BBCMicro (GPL v3) | Softcore (6502/65816) | Acorn permission; ROMs included |
| MSX | MSX1/MSX2/MSX2+ | MiSTer MSX (GPL v3) | Softcore (Z80) | Open BIOS included |
| Amstrad CPC | 464/664/6128/Plus | MiSTer Amstrad (GPL v3) | Softcore (Z80) | Amstrad permission; ROMs included |
| Apple II | II/II+/IIe/IIc/IIgs (partial) | MiSTer AppleII (GPL v3) | Softcore (6502/65816) | PD ROMs included; IIgs user-supplied |
| PC / DOS | XT/AT/386/486 | ao486 (GPL v2) | Softcore (x86) | FreeDOS/SeaBIOS free; MS-DOS user-supplied |
| Homebrew | Agon/RC2014/LM80C | Open source cores | eZ80/Z80 | All firmware free; included |
| Nintendo | NES/Famicom/FDS/SNES/SGB | MiSTer NES + SNES (GPL v2) | Softcore (6502/65816 switchable) | No OS required |
| Atari 2600/7800 | Atari 2600/VCS/7800 | MiSTer 2600 + 7800 (GPL v2) | Softcore (6507/6502C) | 7800 BIOS optional; replacement included |
| Sega Mega Drive | MD/Genesis/Mega CD | MiSTer Genesis (GPL v2) | Softcore (68000+Z80) | BIOS where free |
| Sega Master System | SMS/Mark III/Game Gear | MiSTer SMS (GPL v2) | Softcore (Z80) | No OS required |
| GBA | Game Boy Advance | MiSTer GBA (GPL v2) | Softcore (ARM7TDMI) | No OS required |
| Arcade | Multiple systems | Jotego + MiSTer (GPL v3/v2) | Mixed | ROM sets user-supplied |