FireStorm

FireStorm is the Ant64's chipset — its CPU (the EE), graphics, and audio fused on a single FPGA. The "main CPU" and "custom chip" are the same silicon — the part of Ant64 where graphics, audio, and software are not just rendered, but performed.

CPU and Chipset in One

Most modern systems split work between a general-purpose CPU and a separate GPU or chipset, connected over a bus (PCIe, AXI, AHB). Every interaction across that bus costs latency and predictability. The Ant64 puts the CPU and the chipset on the same FPGA, sharing the same memory ports, the same scratchpad BSRAM, and the same clock domain.

This means:

• The CPU writes a sprite attribute and the next scanline reflects it.
• The CPU starts a blit and the blitter responds in the same cycle, with completion visible in a register before the next instruction.
• The CPU programs the Copper and the Copper modifies palette mid-scanline.
• The CPU is part of the timing graph alongside Tempest (audio) and Blaze (graphics).

There is no driver. There is no kernel mode-switch. There is no "GPU command buffer". The CPU just uses the chipset, the way a 68000 used Paula and Denise.

FireStorm Execution Engine

The CPU at the heart of FireStorm — the EE (Execution Engine) — is a 64-bit RISC-V core — fully RV64GC compatible so existing RISC-V code runs unmodified — plus a stack of eight custom extensions — seven designed for the Ant64's own workloads, and Xez, the Z80-style flag model:

• Xcrisp — memory primitives (auto-inc, indexed addressing, memory-fused arithmetic, block memory, B-tree primitives, PIC family, compare-mem-branch)
• Xstack — hardware BSRAM stacks for U/S/M privilege
• Xcond — predicated R-type instructions
• Xlate — per-register memory translators (endian swap, bit-reverse, etc.)
• Xctx — hardware context switching (32 contexts)
• Xmath — games / audio / DSP math (fused MAC, saturating, transcendentals, BAM trig, vector bundles, 2D math, quaternion, distance heuristics)
• Xwide — 64-register file and wider immediates in wide mode
• Xez — the Z80 flag model: an ezflags register (Z/C/S/V/P), flag-setting arithmetic and shifts, flag branches, and decrement-and-branch. The register is a shared EE facility — Xmath's carry and Xcrisp's block-compare write it too

A ninth extension, Xaccel, is provisional (concept-stage) — coprocessor offload from FireStorm to the DeMon CM5 (over PCIe) and to the on-die hard RISC-V core (over AXI), with results returned through the register scoreboard like a long-latency multiply. It isn't one of the settled eight; see ee_xaccel.

The microarchitecture is shallow out-of-order: in-order issue with register scoreboarding for out-of-order completion, both RVC-pair and 32-bit-pair dual-issue. DSP-block-backed multipliers. ~380 MHz on the GoWin GW5AST.

FireStorm EE specification »

The Real-Time Chipset

Around the CPU on the same FPGA, FireStorm runs in lockstep with the video beam:

• Hardware sprites, layers, palettes, and raster effects managed directly in hardware
• Blitter primitives — hardware sprites, tilemaps, and more driven by Copper or by the FireStorm EE
• Objects can be placed on screen instantly and modified while a frame is being drawn
• Audio synthesis shares the same precise timing domain — sound and visuals stay perfectly synchronised
• Because it operates on scanlines rather than pixels, the system scales naturally — trade resolution for object count and effects as needed
• Dedicated hardware resources remain always available for overlays, cursors, and diagnostics
• Colony Connection (on hold under the CM5 design — both FPGA SerDes blocks are committed to DisplayPort + PCIe; may return in reduced form on spare IO pins) — a high-speed connection between Ant64 computers and peripherals. Colony Connection

The Copper

The Copper is a beam-synchronised list processor — the Amiga's defining trick, brought back. It executes a list of operations tied to scanline position:

• Modify any chipset register at a specific scanline
• Modify palettes mid-scanline
• Inject commands into the command-list rendering layer
• Trigger FireStorm EE interrupts at exact beam positions

Combined with the Copper's cycle-exact beam timing, this lets you do tricks that were impossible on the original Amiga: mix the CPU into the raster loop. The Copper wakes a paused FireStorm context (via Xctx HALT/RESUME) at a specific scanline, FireStorm runs a few hundred cycles of game code, and yields back before the next scanline. The determinism that carries this is the Copper's, not the CPU's — a scanline is thousands of FireStorm cycles, so the budget holds comfortably even though the EE itself now runs speed-first rather than to an exact cycle count.

System Frame-Sync Output

FireStorm's display compositor generates a system-wide vertical-sync signal as a dedicated hardware output — a single 3.3 V TTL line that pulses once per display frame, at the moment the last visible scanline has been drawn. The pulse means exactly: the previous frame is done; the compositor is ready to accept the next frame's input. It is the system's frame-rate heartbeat.

Logically the same event drives the analog VGA / SCART vertical-sync pin (see RGB Out), so the entire machine — internal supervisors, external displays, anyone watching the pin on a logic analyser — sees frame edges at the same instant.

   FireStorm chipset draws frame N
        │
        ▼
   ── vsync pulse (last visible line of frame N drawn) ──►   to DeMon, Pulse,
        │                                                    VGA / SCART, …
        ▼
   Pulse pushes frame N+1 over MIPI, DeMon over HDMI (video + audio chunk)
        │
        ▼
   FireStorm composites frame N+1 (supervisor layers + chipset layers)
        │
        ▼
   ── vsync pulse for frame N+1 ──►                         (repeats at the display refresh rate)

What the signal coordinates:

• DeMon and Pulse wait for vsync, then push the next frame of their display layer — UI + sprite + tilemap layers, sent as compact descriptions (cell grid, tile-index map, sprite display list) that FireStorm renders at scanout, not finished pixels — and the next frame's audio chunk along the same link (SID / SAM on DeMon over HDMI, AMY and emulator audio on Pulse over MIPI). Between vsyncs the links are idle. See Composer.
• Anything else with per-frame work — Copper instruction-list swap, Blitter next-frame job-queue swap, application-side per-frame logic — rendezvous on the same pulse if it wants frame-locked behaviour.

Supervisor layer descriptions are tiny — an index-per-cell text grid or tilemap (a full 64×30 cell grid is ~7.5 KB, dirty-cell streaming a few hundred bytes) plus a sprite display list — trivial against the supervisor links' per-frame budget (Pulse's MIPI carries ~6 MB per frame at 60 Hz from its 375 MB/s link; DeMon's HDMI, far more). FireStorm renders each layer and scales it to the active output resolution via per-layer pixel replication (Render Small, Output Big), so a supervisor produces no finished pixels and doesn't have to render at 4K or even 1080p.

Audio chunked per frame keeps audio and video in lockstep without a separate clock — one frame of audio at 48 kHz / 60 Hz is ≈ 800 stereo samples (~3 KB), trivial next to the video.

Direct keyboard input (separate from the frame-sync path) — Clicky, the keyboard controller, has a dedicated UART straight to FireStorm (K2UART / UART5, on Clicky's PG4 / PG5), so a core can read key events with minimal latency without routing through DeMon — for example the eZX Z80 core reading the Spectrum matrix directly. (Placeholder note — pending fuller FireStorm-side integration from the internal doc.)

The FPGA

FireStorm is built on a GoWin GW5AST-138 FPGA (138K LUT4, 298 DSP blocks) on all three boards — Ant64S, Ant64, and Ant64C. The same bitstream architecture targets every board, with the same layer count, scratchpad, and wide-mode SRAM access; the models differ in DDR3 capacity and peripheral set, not in FPGA fabric.

The GW5AST-138 silicon also contains a hard RISC-V coprocessor — an 800 MHz 32-bit RISC-V CPU baked into the FPGA die itself, separate from the FireStorm soft core. It isn't a user-facing CPU: it runs resident system / debug firmware that monitors FireStorm internals at silicon speed (voice states, performance counters, error detection, register inspection), with zero LUT cost since it lives in silicon rather than fabric. See the FPGA reference for details. It's also the candidate near backend for the provisional Xaccel offload extension — a double-precision-FPU RISC-V core, on-die, running compute kernels handed to it by FireStorm.

Full technical details — pin maps, memory architecture, codec wiring, JTAG, hard coprocessor — are covered in the FPGA reference page.

FPGA technical reference »