DeMon — Debug + Monitor

AntOS host, system supervisor, hardware glue, and boot-UI display engine — pronounced "Demon".

DeMon is built around the ESP32-P4 (paired with an ESP32-C5 for wireless) and sits at the centre of everything: it boots the system, programs the FPGA, runs AntOS, watches over every other chip, drives the system display via its MIPI engine, and provides hardware debugging across the entire Ant64.

The choice to host AntOS on DeMon — rather than on the FireStorm Execution Engine inside the FPGA — has one important consequence: AntOS keeps running while the FPGA is being reconfigured. Loading a personality cartridge, flashing a development bitstream, or recovering from a fault all happen without disturbing the OS. The main display blanks only for as long as the FPGA takes to reconfigure — a fraction of a second for the native chipset on a normal boot, somewhat longer for a personality load — and AntOS keeps running on DeMon throughout.

Overview

Why ESP32-P4?

The ESP32-P4 is Espressif's high-performance RISC-V SoC: a single 400 MHz HP RISC-V core for application code, a separate 40 MHz LP RISC-V core for low-power background tasks, integrated MIPI display TX, USB OTG, and 32MB embedded PSRAM. It also has PIE (Performance Instruction Extensions) — Espressif's RISC-V SIMD-like instructions for fast AI inference and DSP. See https://developer.espressif.com/blog/2024/12/pie-introduction/ for an overview of PIE.

PIE on DeMon's HP core gives AntOS access to small ML inference and DSP acceleration: speech recognition, ambient music analysis, font rendering acceleration, image scaling, etc. — all without a separate AI chip.

The integrated MIPI engine is the critical feature for DeMon's display role — it lets AntOS render its UI on the HP core and feed it into the FireStorm FPGA as one of two MIPI display sources. Once the FPGA bitstream is loaded, DeMon's MIPI feed becomes the AntOS UI layer in the chipset's display compositor.

The ESP32-C5 provides wireless connectivity (Wi-Fi 6 dual-band, Bluetooth 5.3, Thread, Zigbee, ESP-NOW) and frees the ESP32-P4 from RF responsibilities. They communicate over an internal SPI / UART link.

Pulse uses the same ESP32-P4 SoC, in a parallel role. Where DeMon hosts AntOS and feeds the system UI to FireStorm's MIPI RX #0, Pulse hosts the music sequencer and feeds the sequencer / mixer / sample-browser UI to MIPI RX #1. Both supervisors share the same toolchain, the same recovery model, and the same internal architecture (single HP core + LP core + 32MB PSRAM + PIE) — they differ only in role, peripheral wiring, and PSRAM use.

Real-Time Clock — MCP74910

• 64 bytes battery-backed SRAM
• 128 bytes EEPROM + 8 bytes protected EEPROM
• Supports years 2001–2399
• Costs less than £1

Responsibilities

DeMon (ESP32-P4 — 400 MHz HP core + 40 MHz LP core)
 |
 ├── Runs AntOS on the HP core (persists across FPGA reload)
 ├── Programs FireStorm FPGA at boot via JTAG
 ├── Drives AntOS UI as MIPI display layer → FireStorm MIPI RX #0
 ├── Sprite layer via 2D-PPA blitter — rotation, scaling, alpha, colour-key
 ├── Triple SID audio engine (L/C/R) — driven by AntOS, FireStorm, and Pulse
 ├── SAM speech synthesizer — text-to-speech for voice prompts / accessibility / dialogue
 ├── QSPI register window → FireStorm chipset
 ├── Bidirectional SPI ↔ Pulse — peer command/data link (master + slave channels)
 ├── SWD debug port → Pulse + QMK (program + debug, emergency recovery only)
 ├── PIE-accelerated AI/DSP for AntOS services + SID engine + sprite blitter
 ├── Streams debug output from each component (including FireStorm internal hard RISC-V coprocessor)
 ├── Remote reset of any component
 ├── USB host → keyboard, mouse, joypad
 ├── 32MB PSRAM available for AntOS, application data, OTA staging,
 │    sprite framebuffers, SID engine audio buffers
 └── LP core (40 MHz) — RTC monitoring, low-power housekeeping, wake handling

DeMon (ESP32-C5)
 |
 ├── Wi-Fi 6 (2.4 + 5 GHz)
 ├── Bluetooth 5.3 LE + Mesh
 ├── Thread 1.3 mesh
 ├── Zigbee 3.0
 ├── ESP-NOW (no router needed)
 └── Optional LoRa via external SX1262

MIPI Display Feed to FireStorm

The ESP32-P4's integrated MIPI DSI transmitter is wired to MIPI RX #0 on the FireStorm FPGA (one of two 2-lane + clock D-PHY receivers — the other, MIPI RX #1, is fed by Pulse).

Specifications:

• 2 data lanes + differential clock (D-PHY)
• Up to 1.5 Gbps per lane = 3 Gbps total (~375 MB/s peak)
• Enough bandwidth for 1280×720 at 60 Hz RGB UI overlay plus headroom for bulk data

FireStorm uses DeMon's MIPI feed as the AntOS UI display layer — the chipset composites it alongside whatever application is running on the FireStorm EE. Recovery menus, file browsers, system status, network state, and the AntOS shell all live here.

When the AntOS UI is idle or transparent, the MIPI link's idle bandwidth is available to carry bulk data into FireStorm's DDR3 (asset uploads, OTA payloads, debug captures).

Sprite-Layer Capability

The ESP32-P4 includes a full hardware 2D Pixel Processing Accelerator (2D-PPA) with rotation, scaling, mirroring, alpha blending, and colour-key support. This means DeMon's MIPI feed is not limited to a flat UI overlay — it can also deliver a fully-featured sprite layer to FireStorm's compositor.

Use cases:

• AntOS-rendered sprites — system icons, file-browser thumbnails, notification badges, animated cursors, status indicators rendered with rotation/scaling on the P4 itself
• Sprite-based overlays for applications — AntOS-side widgets composited over the running game/demo without involving the FireStorm EE
• Effects layer — particle bursts, screen transitions, glyphs, accessibility overlays at any orientation
• Recovery / boot sprites — animated splash, progress indicators rendered before the user-facing application even starts

The 2D-PPA does its work on framebuffers in DeMon's 32MB PSRAM; the resulting composited image is then sent over MIPI to FireStorm. The FireStorm chipset compositor treats the MIPI input as one of its display layers and gives it the standard treatment — priority register, colour key, Copper-controllable per-scanline, visible on all outputs.

Pulse's MIPI feed has the same capability (see Pulse). Between them, the two supervisors can deliver two independent sprite-layer feeds into FireStorm — for example, AntOS overlay sprites on MIPI #0 and music-performance visualisation sprites on MIPI #1.

Display Behaviour: Native Boot vs Personality Load

On a normal power-on or reset, the FPGA auto-loads its native Ant64 chipset from its own attached flash chip. This takes only a fraction of a second — well under what the user perceives as a wait. Once loaded:

• The native chipset is up
• MIPI RX #0 (from DeMon) and MIPI RX #1 (from Pulse) start accepting feeds
• The AntOS UI from DeMon and the sequencer UI from Pulse appear on the main display almost immediately
• Resetting the system always returns the FPGA to this native state — the flash is the canonical source of truth

When the user (or AntOS) loads a personality cartridge — Amiga, Atari ST, C64, etc. — the FPGA temporarily takes on that personality's bitstream instead of the native chipset. This is a more substantial reconfiguration:

• The personality bitstream is loaded into the FPGA's configuration logic (via JTAG from DeMon, or directly from the cartridge depending on the personality)
• Main display is dark for the duration of this load — typically up to ~1 second
• Once the personality is up, its own display pipeline drives the main display

A reset at any time returns the FPGA to its native chipset by re-reading the FPGA flash — discarding the temporary personality and bringing the AntOS UI back. The personality is, by design, an overlay onto the persistent state of the flash; it's never written to flash.

In all cases:

• AntOS keeps running on DeMon, undisturbed
• The keyboard touchscreen stays active, driven directly by DeMon, showing AntOS status, reload progress, recovery prompts, or any other useful information throughout the blackout
• The circular display above the keyboard (driven by Pulse via SPI) also stays active independently
• The blackout window is bounded by FPGA configuration time alone — fast for native, slightly longer for personality

This is intentionally different from the previous design where AntOS ran on the main processor: there's no OS to bring back up, no kernel re-init, no filesystem remount. And even within the blackout window the user has visible feedback via the touchscreen and the circular display.

Triple SID Audio Engine

DeMon runs a three-SID emulator in software on the ESP32-P4 — three instances of the MOS Technology 6581/8580 SID chip, panned Left / Centre / Right for a wide stereo image. Audio rendered by the SID engine is streamed to FireStorm over the MIPI bulk-data path (sharing the link with the AntOS UI feed) and joins the FireStorm mixer as another voice source alongside the chipset audio engine, Pulse AMY, and FireStorm EE application audio.

The SID engine is a shared audio resource: although it lives in DeMon firmware, it can be driven by any of the three CPUs in the system — AntOS on DeMon, FireStorm in the FPGA, and Pulse over its direct SPI link to DeMon (see below). It's an audio engine that happens to be hosted on DeMon, not a private DeMon facility.

What It's For

1. System sounds — alerts, notifications, navigation feedback, error tones, low-battery warnings, the kind of UI audio that should be available the moment AntOS is up, before the user has loaded an application or fired up the sequencer
2. Sound effects for AntOS-side applications — file-browser audio cues, network event sounds, debug audio output, accessibility tones
3. Game and demo sound effects — applications running on FireStorm can trigger SID voices for retro-flavoured sound effects (explosions, alerts, jumps, lasers) without burning chipset audio slots; particularly useful when the chipset voices are committed to music or sample playback
4. Sequencer-driven SID voices — Pulse can route MIDI tracks to the SID engine for compositions that want authentic SID timbre in the mix
5. SID file playback — the engine plays classic .sid files directly; AntOS doubles as a C64 music player out of the box
6. AntOS Luau scripts — algorithmic / generative composition driving the SIDs as a programmable instrument

Why on DeMon?

DeMon is the right host for this because:

• PIE-accelerated — the SID engine's filter math, oscillator mixing, and waveform generation benefit from the ESP32-P4's PIE SIMD extensions, fitting comfortably within available CPU budget
• Independent of FPGA state — the SID engine keeps running even during FPGA reload; system audio is uninterrupted
• MIPI bulk path is already there — no new bus is needed; the SID audio shares the MIPI link with the AntOS UI feed
• Spare CPU on the supervisor — AntOS does not saturate the HP core; the SID engine fits in the headroom

How It's Triggered

The SID engine accepts events from three sources:

The FireStorm path uses a chipset register block as a mailbox: FireStorm writes SID note-on / note-off / parameter events into a small queue, then raises a dedicated IRQ to DeMon over a GPIO line. DeMon reads the queue via its QSPI window into the chipset and dispatches the events to the SID engine. This is the same general mechanism used elsewhere for FPGA-to-supervisor signalling — a few microseconds of latency, dominated by the IRQ-to-handler time on the ESP32-P4.

All three sources can drive the engine simultaneously; SID voices are dynamically allocated to whichever source is asking. Conflict policy (which source gets which SID chip when contended) is configurable in AntOS — typical defaults reserve one of the three SIDs for OS sounds and let games / sequencer share the other two.

Capability

• 3× SID chips (MOS 6581 / 8580 selectable per instance — 6581 for the classic "muddy" sound, 8580 for the cleaner late-era variant)
• 3 voices per SID — 9 total
• Per-voice triangle / sawtooth / pulse / noise waveforms with ring modulation and oscillator sync
• Per-SID multi-mode filter (low-pass, high-pass, band-pass, notch, with resonance)
• L / C / R panning assigning each SID to a stereo position
• CPU cost — roughly 5–10% of the HP core for all three SIDs at full polyphony, well within DeMon's available budget alongside AntOS itself
• Compatibility — the engine can play SID files (the iconic .sid format), letting AntOS act as a C64 music player out of the box

Audio Path

AntOS scripts          Pulse (SPI master)         FireStorm EE
SID file player        sequencer events           game/demo FX
       │                       │                          │
       │              (SPI slave on DeMon)    (chipset mailbox + IRQ
       │                       │                read via QSPI)
       │                       │                          │
       └───────────────────────┴──────────────────────────┘
                               │
                               ▼
                  3× SID emulators (DeMon ESP32-P4, PIE-accelerated)
                               │
                               ▼
                  L / C / R mix to stereo buffer in PSRAM
                               │
                               ▼
                  stream over MIPI link → FireStorm
                               │
                               ▼
                  FireStorm mixer (alongside chipset voices, AMY, application audio)
                               │
                               ▼
                  WM8958 / WM8960 codec

Speech Synthesizer (SAM)

Alongside the Triple SID engine, DeMon runs a retro formant speech synthesizer in the tradition of S.A.M. (Software Automatic Mouth, 1982) — the iconic robotic voice of the Commodore 64, Atari 8-bit, and Apple II era. Like the SID engine it's hosted on DeMon but shared across all three CPUs, and like SID it streams its audio to FireStorm via the MIPI bulk-data path for mixing alongside everything else.

What It's For

1. AntOS system voice prompts — boot messages, error alerts, low-battery warnings, network-event announcements; voice feedback that AntOS can produce the moment it's running, with no application involvement
2. Accessibility — screen-reader mode for menu navigation, spoken descriptions of UI state, audio-first navigation when the main display is busy or unavailable
3. System narration — patch names spoken aloud, file-browser audio cues, status-line readouts
4. Musical use via Pulse — Pulse can send text or phoneme events to DeMon over the SPI link; the rendered speech enters the mixer as another voice source. SAM-style robotic vocals as a musical instrument — sequencer-driven phoneme streams, vocoder leads, "talking" basslines
5. Game / demo dialogue from FireStorm — applications running on FireStorm can request SAM speech via the chipset mailbox; iconic robotic voice-acting at the cost of a few register writes
6. AntOS Luau scripts — algorithmic narration, text-to-speech for arbitrary AntOS text

Why on DeMon?

• AntOS owns voice prompts and accessibility — the OS is where text-to-speech requests originate; hosting the engine on the same chip makes the path direct
• PIE-accelerated — formant synthesis (additive partials at three formants per phoneme) benefits from PIE SIMD
• Available before applications — boot-time voice prompts work without any application running
• Same dispatch model as SID — three trigger sources, MIPI audio out, mixer-side handling identical to SID

How It's Triggered

The same three-source pattern as the Triple SID engine:

Pulse can send either complete text strings (DeMon's Reciter does the text-to-phoneme conversion) or pre-converted phoneme streams (for tighter musical timing).

How It Works

SAM converts text to speech in two stages:

Text input
    │
    ▼
Reciter (text-to-phoneme)
    Text → phoneme string using English pronunciation rules
    e.g. "HELLO" → /HH EH L OW/
    │
    ▼
Phoneme-to-speech (formant synthesis, PIE-accelerated)
    Each phoneme → three formant frequencies (F1, F2, F3)
                 → three formant amplitudes (A1, A2, A3)
                 → pitch contour
                 → voiced/unvoiced classification
    Combined via additive synthesis → audio samples
    │
    ▼
PCM audio buffer → streamed to FireStorm via MIPI link
                    → joins the FireStorm mixer

The formant synthesis produces the characteristic 1980s robotic voice — not because the algorithm is simple, but because it deliberately computes speech with limited resolution (originally 8-bit samples, low sample rate). On the Ant64, running at full ESP32-P4 speed with the output going to the WM8958 codec via FireStorm's mixer, the algorithm is authentically SAM-like but with modern fidelity. The output sample rate is configurable; the engine can run at the original ~7 kHz for full retro flavour, or at 48 kHz for cleaner integration with the rest of the audio path.

Implementation

The open-source C port of SAM (s-macke/SAM, ~39 KB) runs as a bare-metal function on the ESP32-P4. No OS involvement is needed for the inner rendering loop — AntOS / Pulse / FireStorm submit requests, the SAM engine renders into a buffer in DeMon's PSRAM, and the buffer is streamed out over MIPI as part of DeMon's audio output to FireStorm.

Parameters (matching original SAM)

Preset Voices (matching original SAM manual)

Extensions Beyond SAM

The ESP32-P4 has far more processing power than the original 6502 host. The engine can be extended beyond the historical SAM algorithm:

• Higher sample rate output (original SAM: ~7 kHz; DeMon can render at 48 kHz)
• Smoother formant interpolation between phonemes
• Additional phoneme sets (non-English languages)
• Pitch envelope per phoneme (more natural intonation)
• The Pi Zero 2W accelerator (when fitted) can assist with neural TTS for more natural speech, while DeMon retains the retro formant mode

Audio Path

AntOS scripts          Pulse (SPI master)         FireStorm EE
voice prompts          text / phoneme events      app dialogue events
accessibility          for musical use            via chipset mailbox + IRQ
       │                       │                          │
       └───────────────────────┴──────────────────────────┘
                               │
                               ▼
                  SAM Reciter (text → phonemes, when needed)
                               │
                               ▼
                  SAM formant synthesis (DeMon ESP32-P4, PIE-accelerated)
                               │
                               ▼
                  PCM buffer in DeMon PSRAM
                               │
                               ▼
                  stream over MIPI link → FireStorm
                               │
                               ▼
                  FireStorm mixer (alongside SID, chipset voices, AMY, application audio)
                               │
                               ▼
                  WM8958 / WM8960 codec

DeMon ↔ Pulse — Bidirectional SPI Link

DeMon and Pulse are connected by two SPI channels that form a full bidirectional command/data link between the two supervisors. Each chip has both a master and a slave SPI port wired to the other.

This is not a hierarchical supervisor link any more — DeMon and Pulse are peers. Either side can initiate a transaction at any time; the slave side accepts whatever the master sends. AntOS arbitrates its end; Pulse firmware arbitrates the other. The same two ports also carry the firmware-update flow (DeMon can SWD-program Pulse for emergency recovery, but day-to-day operation uses the SPI link).

Wireless — ESP32-C5

Debug Connectivity

Optional: Waveshare Core1262 HF LoRa Module (SX1262) for LoRaWAN and/or Meshtastic use.

Anti-Brick

The ESP32-C5 can remotely unbrick DeMon over Wi-Fi, or via the ICP cartridge port — even if the ESP32-P4's firmware is corrupted.

Keyboard Touchscreen — Always-Available Display

In addition to the MIPI feed into the FPGA, DeMon owns a touchscreen on the keyboard itself (a small TFT panel, capacitive touch, SPI-connected). This screen is wired directly to the ESP32-P4 and is completely independent of the FPGA — it has its own controller, its own framebuffer in PSRAM, and its own touch input path.

This matters because the touchscreen is visible at all times:

• At power-on, the FPGA loads its native Ant64 chipset from its own flash in a fraction of a second — but during that brief moment, before MIPI RX is active, the touchscreen is already showing AntOS boot status, the current boot phase, or a splash logo. By the time the user is consciously waiting for the screen to come up, it is already up.
• During FPGA reload (personality cartridge swap, bitstream update, recovery), the main display blanks while the FPGA reconfigures — typically up to ~1 second for a full personality bitstream, a fraction of a second for a native-chipset reset. The touchscreen continues to show AntOS status, progress, and any interactive prompts throughout.
• During normal operation, the touchscreen is a secondary display surface — AntOS can render system status, the file browser, settings, debug info, soft keys, or jog-dial-style controls here.

Combined with Pulse's circular display above the keyboard (see Pulse), the Ant64 has two always-on auxiliary displays that survive any FPGA state — useful for diagnostics, recovery, and informational UI that needs to be visible even when the main display compositor isn't running.

SPI1 — Device Select

DeMon's ESP32-P4 uses SPI1 with different CSn lines to control multiple devices:

Smart Cart — Cartridge Port

A 30-pin edge connector (42 mm, 2.54 mm pitch) connected to DeMon's ESP32-P4.

• If a cart is present at boot, it is used in preference to the SD card
• Cart insertion/swap whilst powered on triggers an automatic reboot (can be disabled)
• Cart can be safely removed whilst powered on — no reboot
• Reinserting the same cart also does not reboot

Pin Layout

• Pins 1/A and 15/O extend further (power-first mating)
• A ROM cart can be a simple single-sided PCB (letter/top side only)
• The bottom side supports enhanced Pulse cartridges
• Port allows in-circuit programming of DeMon via ICP

NFC Card Cartridge (Special)

A special NFC card cartridge provides:

• NFC reader via I2C with IRQ
• Hardware reset
• MicroSD card slot for game cache

The NFC card carries the web location or ID of the game plus a unique serial number. It can transfer data on first load, then serve future loads from the MicroSD slot in the cartridge itself.

Neopixels — 8 Status LEDs

During self-test all LEDs go white, then change individually: green = passed, red = failed. LED functions are documented and can be repurposed if needed.

What DeMon Can Reprogram

• FireStorm FPGA bitstream (via JTAG) — without interrupting AntOS
• FireStorm FPGA flash (via JTAG chain)
• Pulse (via SWD)
• Sticky (via UPDI through Pulse)
• QMK keyboard controller (via SWD)
• ESP32-C5 (via SPI bootloader)

The ESP32-P4 itself can be reprogrammed over USB or via the cartridge ICP port. Because AntOS lives on DeMon, reprogramming DeMon is a deliberate, deeper-recovery operation — it reboots the OS. Recovery is layered: if DeMon is bricked, the ICP cart can reflash it; if everything is bricked, JTAG access from a PC can rebuild the system from scratch.

If anything goes wrong — Ant64 can heal itself.

Prototype

The prototype uses an Olimex ESP32-P4-PC board. This provides a network RJ45 connector and a MIPI-DSI-to-HDMI output for the display; io36 is pulled to 3v and io35 (boot) is pulled to 3v.

DeMon's own USB-Serial-JTAG goes to the USB-C power port — providing power, console, and JTAG debug over a single cable.

The HS USB port carries bulk storage: B: directly, or B: + B!: via a user-supplied HS hub. (On the production board this becomes a fixed two-port HS hub.)

The FS USB port drives a CH334 FS-only hub, fanning out to: the internal keyboard, the ESP32-C5's USB-Serial-JTAG, Pulse's USB-Serial-JTAG, and an external port for mouse / extra peripheral.

All speed classes are kept pure — no mixed-speed traffic on either hub — which avoids the IDF host stack's TT-not-supported limitation. Dual-host operation is enabled via peripheral_map = BIT0 | BIT1 in the USB host config.

SPI3 is QPI to FireStorm LPSPI is slave to Pulse

A Note on the Previous Architecture

In earlier prototypes, DeMon acted only as a low-level supervisor, with AntOS hosted on a separate application SoC. Consolidating AntOS onto DeMon's ESP32-P4 (paired with an ESP32-C5 for connectivity) brings several benefits:

• AntOS persistence across FPGA reload — bitstream changes no longer require an OS reboot, only a brief screen blackout (a fraction of a second for the native chipset; up to ~1 second for a personality)
• One coherent OS processor — AntOS runs entirely on DeMon's ESP32-P4 rather than being split across a separate application SoC
• 32MB PSRAM — enough for AntOS, application data, and OTA staging
• Native MIPI display engine — DeMon drives its UI directly into the FPGA as a composited layer
• PIE extensions — small AI / DSP acceleration available in the OS without a separate accelerator chip
• Native Wi-Fi 6 + BT 5.3 + Thread + Zigbee via the ESP32-C5
• Simpler power tree — both ESPs are 3.3 V parts with well-characterised power management

The trade-off is that FireStorm in the FPGA is no longer an OS host — it runs user applications, games, demos, and real-time chipset interaction code, while AntOS-level services (filesystem, network, scheduler, UI, debug server) live on DeMon. The two communicate via the QSPI register window and the MIPI link.

Reference Links

• ESP32-P4 — espressif.com/en/products/socs/esp32-p4
• ESP32-C5 — espressif.com/en/products/socs/esp32-c5
• PIE — Performance Instruction Extensions
• JTAG — github.com/kholia/xvc-pico
• JTAG — github.com/phdussud/pico-dirtyJtag