Accelerator — AntOS Compatibility Layer

There is no separate accelerator board any more. When a personality expects one, AntOS provides its functions and quietly redirects them to the Ant64's own hardware.

What changed

Earlier designs carried an optional Raspberry Pi Zero 2W on the FPGA's expansion header — a coprocessor slot for compute-heavy work. That's gone. DeMon is now a Raspberry Pi Compute Module (CM4 / CM5): a quad-core ARM with a real OS already sits at the centre of the system, so a second Pi bolted onto the FPGA would only duplicate what DeMon already is. The physical accelerator slot has been removed.

What survives is the idea of an accelerator — and the name. It now names two things at once: the software compatibility layer in AntOS described below, and the FPGA-side module every image wires up to for display, sound, input, and redirect. The name fits both — it accelerates the running system, by redirecting a personality's would-be accelerator calls to hardware that vastly outperforms the board they replaced, and it accelerates getting a new FPGA image working in the first place, since any source wires up to the Accelerator module rather than building those functions from scratch.

The compatibility idea

Some personalities were designed for a machine that had an accelerator and its peripherals. The clearest example is the eZX Spectrum — modelled on hardware where a companion board (and its ESP Wi-Fi, its real-time clock, its storage) provided services the base machine lacked. Software written for that machine reaches for those peripherals by their original addresses and protocols.

The Ant64 doesn't have that board. Instead, AntOS implements the same functions and redirects the calls to the Ant64's native equivalents. When a personality's core — loaded onto the FPGA as a replacement image, not running alongside FireStorm — accesses what it believes is its accelerator, the access is trapped and serviced by the real Ant64 subsystem — transparently, so unmodified guest software behaves as if the original peripheral were present.

FireStorm is not running underneath a loaded personality. Loading a replacement image displaces it — the personality's own CPU and chipset occupy the fabric FireStorm would otherwise use. What's present in every image, personality or native, is not the full FireStorm CPU and chipset alongside the guest core — it's the Accelerator module: a minimal FPGA block that any FPGA source, existing or new, wires up to in order to get display, sound, inputs, and accelerator-redirect functions working. Every image includes this module rather than reimplementing those functions itself; it's the thing this redirection layer is actually built on, and it's where the name comes from twice over — see What changed above.

What redirects to what

The list is open-ended: any service a personality's accelerator provided can be mapped onto whichever Ant64 subsystem already does that job.

Some of these map especially cleanly. A Spectrum-era machine typically talks to its Wi-Fi over an ESP AT-command link — and Phreak is an ESP driven by an AT-command interface, so the guest's networking calls land almost natively. The clock is similar: the peripheral the guest expects to read becomes a read of the MCP79410.

How it works

A personality's peripheral I/O is a set of well-known registers or ports. The Accelerator module — the minimal FPGA block every image wires up to for display, sound, inputs, and accelerator-redirect functions (for low-level ports) or AntOS (for higher-level services) — recognises accesses to those addresses and forwards them to the matching AntOS service rather than to absent hardware:

• Reads return live data from the real subsystem — the current time from the MCP79410, a link-status word from Phreak, a directory listing from DBFS.
• Writes become requests to the real subsystem — open a socket on Phreak, set an alarm on the RTC, write a file to DBFS.
• Timing and semantics are shimmed to match what the guest expects, so software that polls a status register or waits on a flag still sees the behaviour it was written for.

Because the services live in AntOS (on the CM) and in the Phreak / DeMon hardware, they keep working across FPGA reconfigurations — the same way the rest of the supervisor does.

Performance is a non-issue. The original accelerator on a machine like the Spectrum Next is a Pi-Zero-class part; DeMon's CM4 / CM5 is many times faster — quad Cortex-A72/A76 against that, with far more RAM and a real GPU. The redirection shim adds only the cost of trapping an access and calling into a service that is itself running on hardware orders of magnitude quicker than what the guest was written for. There is no headroom problem: the machine servicing the request vastly out-classes the accelerator it stands in for.

Why this beats a board

• Nothing to fit, nothing to power. The functions are already in the machine — no socket, no second Linux to boot, no extra idle draw.
• One set of hardware. Wi-Fi is the Wi-Fi (Phreak), the clock is the clock (the MCP79410), storage is the filesystem (DBFS) — no divergence between a "main" set and an "accelerator" set to keep in sync.
• Personality-agnostic. Each personality maps its own expected peripherals onto the same shared Ant64 services; supporting a new one is a matter of describing its redirections, not adding hardware.

Graphics — the always-available chipset

The Accelerator provides the Ant64's graphics on the same principle it provides everything else: an always-available software graphics chipset, rendered by DeMon and composited around whatever the FPGA is outputting. It is the rich realisation of the display the Accelerator module gives every image — any image, personality or native, can draw sprites, tilemaps, and particles through it, on an over-plane above the FPGA output and an under-plane below it. So the Accelerator can enhance a retro system's graphics the same way it stands in for its peripherals: a HUD or particle layer on top, parallax scenery behind, over an unmodified guest.

It renders on either the FireStorm hardware chipset or the always-available software planes, and composites over HDMI using the CM5's two video outputs. The full model — the two backends, the over/under sandwich, transparency over HDMI, and how it fits the CM5's fast path — is in Accelerator — Graphics (Luau: require("accelerator")).

The Accelerator also carries the CM's sound: HDMI carries audio as standard, so the CM's audio (AntOS sounds, the Triple SID engine, game / script audio) rides the same HDMI link, embedded in the stream, and FireStorm's RX drops it into the mixer beside the Tempest voices — one source among several, alongside Pulse's AMY synthesis and MIDI. The module's sound remit is met by the CM's own audio over the same link, added to the accelerator system's mixer. See Accelerator — Graphics § Audio.

Native offload

Native FireStorm code — running as FireStorm, not as a loaded personality — reaches the same CM coprocessor, over the same PCIe link, as an explicit offload target — posted fire-and-forget writes for streaming and rendering, and scoreboarded reply offloads (a pending result register, exactly like a long-latency multiply) for values it needs back. That is an execution-engine mechanism — EE pseudo-instructions plus a shadow window and mailbox — specified separately in the Xaccel extension (ee_xaccel).

The redirection layer above and Xaccel are two paths to one resource: a personality reaches the CM by redirection; native FireStorm code reaches it through Xaccel.