Ant64 Graphics Architecture - A Chipset, Not a GPU

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

Where modern GPUs optimize for throughput and abstraction, Ant64 optimizes for:

• Predictability
• Low-latency control
• Creative misuse
• Tight synchronization with audio

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

Architectural Overview

Graphics rendering is handled by the Razz 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 components are memory-mapped devices, visible to:

• SG2000
• Jazz
• DeMon

Layer System

Layer Model

Ant64 supports up to 16 independent layers, each of which can be assigned a type at runtime. Layers are:

• Independently addressable
• Independently scrollable
• Independently clipped
• Optionally Z-aware or Z-agnostic during merge

Layer order is programmable and can change per scanline via the Copper.

Layer Types

Each layer may be one of the following:

Raster Pixel Layers

• 3 bpp text mode (7 colours + transparency)
• 6 bpp indexed mode
• 9 bpp indexed mode (palette-based)
• 12 bpp direct colour (4-4-4)
• 12 bpp palette-indexed (64 palettes × 64 colours)
• 18 bpp direct colour
• 36 bpp HDR / extended mode

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

Tilemap Layers

• Traditional 2D tilemaps
• Variable tile sizes
• Fine scrolling with hidden edge buffers
• Palette
• Rotation
• Flip
• Depth bias
• Tilemaps may reside in SRAM or DDR3

Tilemap layers are designed to replace entire background engines from:

• SNES
• Megadrive
• 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

Designed for:

• Consoles
• Debug overlays
• Retro-style UIs
• Terminal-style environments

Vector Layers

• Line and curve primitives
• Colour changes mid-path
• SVG-like command lists
• Resolution-independent

Ideal for:

• Vectrex-style games
• HUDs
• Oscilloscope-style visuals
• Music visualisation

Command List Layers

• Designed to consume 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 not a special layer — they are rendered primitives. Supported features:

• Arbitrary size
• Scaling
• Rotation
• Palette or direct colour
• Z-depth
• Optional pixel perfect collision detection via Z-buffer flags

Sprite textures typically reside in DDR3 for capacity and bandwidth.

Primitives

Built-in primitives include:

• Lines
• Rectangles
• Polygons
• Textured triangles
• Tilemap draw primitives
• Vector paths

Primitives may:

• Write to Z-buffer
• Ignore Z-buffer
• Trigger interrupts on collision

Z-Buffer System

Ant64 includes a hardware Z-buffer that is:

• Optional per layer
• Optional per primitive
• Configurable during merge

This allows:

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

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
• Can modify registers mid-frame
• Can trigger update units
• Can control audio and graphics together

This enables:

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

The Blitter Engine

The Ant64 includes a fully hardware Blitter, implemented inside the Razz FPGA.

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

What the Blitter Is

The Blitter is a dedicated DMA-driven unit that performs high-speed memory-to-memory operations without CPU involvement.

Unlike modern GPUs, which abstract this behaviour behind APIs, the Ant64 Blitter is:

• Explicit
• Predictable
• Memory-address driven
• Cycle-deterministic

This makes it as useful for real-time effects as it is for bulk rendering.

Supported Operations

The Blitter supports:

• Copy
• Fill
• Masked copy
• Pattern fill
• Line draw
• Area scroll
• Block rotate (90°, 180°, mirror)
• Combine 'n' bitplane to chunk conversion
• Split chunk to 'n' bitplane conversion
• Packed ↔ planar format transforms

These operations can target:

• Screen memory
• Off-screen buffers
• Tilemaps
• Sprite sheets
• Audio wave tables
• Copper lists

Logical Operations

The Blitter supports logical combination modes, including:

• AND
• OR
• NOT
• XOR
• MIN / MAX
• SHIFT (bit-accurate, not pixel aligned)
• Alpha-controlled merge
• Palette-index-aware masking

This enables:

• Hardware compositing
• Stencil effects
• Shadow casting
• Dynamic transparency
• Feedback-based visuals

Chained Blit Operations

Blit operations can be:

• Chained
• Queued
• Triggered by interrupts
• Triggered by Copper instructions

This allows entire rendering pipelines to be constructed without CPU loops. For example:

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

All executed deterministically every frame.

Blitter + Z-Buffer

The Blitter can optionally:

• Write Z values
• Respect existing Z values
• Ignore Z entirely

This enables:

• Depth-aware bulk rendering
• Occlusion-aware scrolling
• Hardware-assisted isometric engines

Blitter + Audio

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

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

This allows:

• Waveform morphing
• Sample layering
• Time-domain effects
• Preprocessing for DSP units

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

They exist for:

• Graphics
• Audio
• Copper lists

his allows the CPU to describe 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 terrain-like visuals
• Memory-efficient

Ideal for:

• Heightmaps
• Scrolling landscapes
• Pseudo-3D racers

Depth-Enhanced Tilemaps

• Tiles can have thickness
• Hardware-generated side faces
• Roof/ceiling visibility

Works for:

• Top-down games (Zelda-like)
• Side-scrollers (Mario/Sonic-style)

Sprites interact with this via the Z-buffer, preventing “floating” artifacts.

Razz Planar Surfaces & Bitplane Processing

Razz does not expose planar (bitplane) graphics as a display mode. Instead, it introduces Planar Surfaces as a first-class memory and Blitter resource.

This preserves the enormous creative power of planar representations — famously exploited by Amiga demo coders — without burdening the display pipeline with legacy constraints. Planar Surfaces are designed 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
• Modern chunky, tile, and sprite layers

What Is a Planar Surface?

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

• Each plane is a contiguous bitmap
• All planes share identical dimensions
• Planes are logically stacked to form multi-bit pixels

Typical configurations:

• 1 plane = 1-bit mask
• 2-4 planes = low-bit indexed data
• 5-8 planes = full 8-bit indexed data

Unlike legacy systems:

• Planes are not tied to scanline fetch
• Planes are not tied to palettes
• Planes are not tied to display timing

They are pure data.

Output Pipeline

• Internal render resolution is decoupled from output resolution
• Line buffers can repeat pixels or lines as needed
• Multiple outputs may select different layer subsets

Supported outputs:

• HDMI
• Analog RGB (SCART, VGA, etc)
• DisplayPort (Creative Edition)

Each output can:

• Choose which layers to display
• Apply different scaling
• Use different colour formats
• 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, Razz’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.