Ant64 Graphics Architecture — A Chipset, Not a GPU

FireStorm's graphics system is designed to be played as much as programmed.

Design Philosophy

The Ant64 graphics system is not a traditional GPU, and it is not a fixed-function retro display chip. It is a programmable, deterministic, multi-layer visual instrument, inspired by:

• The Amiga's Copper and Blitter, and Atari ANTIC / GTIA
• Arcade hardware layering and sprites
• Demo scene timing tricks
• Vector and raster hybrids
• Modern compositing pipelines

The result is something closer to a custom chipset than a GPU — deliberately so.

Architectural Overview

Graphics rendering and audio synthesis are handled by the FireStorm FPGA, which contains:

• A multi-layer raster engine
• Sprite and primitive renderers
• Tilemap and text engines
• Vector and ray-based extensions
• A hardware Z-buffer
• A Copper-style control processor
• Update Units for bulk and procedural changes

All graphics and audio components are memory-mapped devices, visible to the SG2000, Pulse Sequencer, and DeMon.

Layer System

Layer Model

Ant64 supports up to 16 independent layers, each assignable to a type at runtime:

• Independently addressable, scrollable, and clipped
• Optionally Z-aware or Z-agnostic during merge
• Layer order is programmable and can change per scanline via the Copper

Layer Types

Raster Pixel Layers

Palette-based layers are resolved during merge, not storage.

Tilemap Layers

• Traditional 2D tilemaps with variable tile sizes
• Fine scrolling with hidden edge buffers
• Per-tile: palette, rotation, flip, depth bias
• Tiles may reside in SRAM or DDR3

Designed to replace entire background engines from SNES, Megadrive, and arcade boards.

Text Layers

• Character-cell based, packed 36-bit cells (2 characters per word)
• Hardware scrolling (coarse + fine)
• Optional shadowing, palette resolved at render time

Ideal for consoles, debug overlays, retro-style UIs, and terminal environments.

Vector Layers

• Line and curve primitives with colour changes mid-path
• SVG-like command lists, resolution-independent

Ideal for Vectrex-style games, HUDs, oscilloscope-style visuals, and music visualisation.

Command List Layers

• Consumes draw command streams
• Compatible with immediate-mode UI systems (e.g. ImGui-like)
• Copper can inject or modify commands mid-frame

This allows modern UI systems to coexist with retro rendering paradigms.

Sprite and Primitive System

Sprites

Sprites are rendered primitives, not a special layer:

• Arbitrary size · Scaling · Rotation
• Palette or direct colour · Z-depth
• Optional pixel-perfect collision detection via Z-buffer flags
• Textures typically reside in DDR3

Primitives

Z-Buffer System

The hardware Z-buffer is optional per layer and per primitive:

• True depth-aware 2D / 2.5D scenes
• Isometric layering
• Faux-3D tile depth effects
• Sprites exist inside scenes, not just on top of them

Layers can explicitly opt out of Z-based merging to preserve classic ordering when needed.

Copper System

The Copper is a lightweight control processor that executes instruction lists synchronised to raster position:

Copper instruction list
    |
    ├── Modify registers mid-frame
    ├── Trigger update units
    ├── Control audio and graphics together
    └── Fire at any scanline position

Enables:

• Raster splits and per-scanline palette changes
• Dynamic layer reveals
• OS-style draggable screens
• Music-synchronised visual effects

The Blitter Engine

The Blitter is not a legacy compatibility feature — it is a primary performance and creativity engine.

The Blitter is a dedicated DMA-driven unit that performs high-speed memory-to-memory operations without CPU involvement. Unlike modern GPUs, the Ant64 Blitter is explicit, predictable, memory-address driven, and cycle-deterministic.

Supported Operations

• Copy · Fill · Masked copy · Pattern fill
• Line draw · Area scroll
• Block rotate (90°, 180°, mirror)
• Bitplane ↔ chunky conversion (packed/planar transforms)

Logical Combination Modes

AND · OR · NOT · XOR · MIN/MAX · SHIFT (bit-accurate) · Alpha-controlled merge · Palette-index-aware masking

Enables: hardware compositing, stencil effects, shadow casting, dynamic transparency, feedback-based visuals.

Chained Blit Operations

Blits can be chained, queued, and triggered by interrupts or Copper instructions — allowing entire rendering pipelines to run without CPU loops:

Clear background
    → Scroll playfield
        → Draw tile layer
            → Draw sprites
                → Post-process result

All executed deterministically, every frame.

Blitter + Z-Buffer

The Blitter can write Z values, respect existing Z values, or ignore Z entirely — enabling depth-aware bulk rendering, occlusion-aware scrolling, and hardware-assisted isometric engines.

Blitter + Audio

Uniquely, the Blitter is not limited to graphics memory. It can also operate on:

• Audio sample buffers · Wave tables
• Granular synthesis buffers · FM operator tables

Enabling: waveform morphing, sample layering, time-domain effects, and DSP preprocessing.

Update Units

Update Units are hardware engines for structured bulk modification. They can:

• Move overlapping memory regions
• Clear blocks efficiently
• Update structured data (sprites, tiles, audio voices)
• Unpack compressed or packed data streams

Available for: graphics · audio · Copper lists

The CPU describes work instead of performing it.

Advanced Rendering Extensions

Raycasting Unit

• Grid-based ray queries, returns collision cell and distance
• Ideal for Doom-style engines, visibility checks, AI line-of-sight

Voxel Column Extension

• Column-based height rendering — extremely fast, memory-efficient
• Ideal for heightmaps, scrolling landscapes, pseudo-3D racers

Depth-Enhanced Tilemaps

• Tiles can have thickness — hardware-generated side faces and roof/ceiling visibility
• Works for top-down games (Zelda-like) and side-scrollers (Mario/Sonic-style)
• Sprites interact via the Z-buffer, preventing "floating" artefacts

Planar Surfaces & Bitplane Processing

FireStorm does not expose planar graphics as a display mode. Instead it introduces Planar Surfaces as a first-class memory and Blitter resource — preserving the creative power of bitplane representations without burdening the display pipeline.

What Is a Planar Surface?

A Planar Surface is a memory object composed of multiple 1-bit planes:

Unlike legacy systems, planes are not tied to scanline fetch, palettes, or display timing. They are pure data.

What Planar Surfaces Are For

• High-speed bitwise effects · Masking and stencilling
• Feedback and interference patterns
• Procedural and algorithmic visuals
• Software-style renderers accelerated in hardware

They integrate cleanly with the Blitter, Copper, Z-buffered layer merging, and all modern chunky/tile/sprite layers.

Output Pipeline

Internal render resolution is decoupled from output resolution:

Each output can independently choose which layers to display, apply different scaling, use different colour formats, and apply different raster line effects.

Intent and Legacy

Ant64 graphics are not about brute-force polygon counts. They are about:

Expressiveness. Timing. Control. The joy of bending hardware to your will.

Just as the Amiga's Blitter and Copper became creative tools in their own right, FireStorm's graphics system is designed to be played as much as programmed.

The expectation is not that developers will merely reproduce classic visuals — but that they will discover new ones that only exist because this hardware behaves the way it does.