Ant64 Proposed Boot Intros

Overview

The Ant64 boot intro is a procedurally generated, hardware-accelerated opening sequence that plays every time the machine powers on. Inspired by the FM Towns Marty's iconic startup — and the original Amiga Boing Ball demo that defined what personal computers could do in 1984 — the Ant64 intro is both a piece of visual and audio theatre and a practical showcase of what FireStorm, Pulse, and the machine's display system and audio system are capable of.

No two boots are identical. The sequence is assembled from six independent variant slots, each rolling from a weighted random table. Some combinations are common. Some are rare enough that owners will describe them to people who haven't seen them yet. A handful of calendar-triggered themes transform the sequence on significant dates. The rarest combinations are legendary.

Certain variants go further still — a rotoscoped AI-generated figure dances to a live rave MOD track played directly by the EE, both running entirely within FireStorm with no dependency on any other subsystem. The machine is performing at full capability before the operating system has finished mounting its filesystems.

Crucially, the intro is not decoration layered on top of the boot process. It is the boot, from the user's perspective. While something beautiful plays on screen, the rest of the system initialises invisibly. By the time the logo locks and the final note sounds, the machine is ready.

Boot Architecture

The Timeline

The GW5AT-138 loads its bitstream autonomously from its own dedicated SPI flash on power-up. No external orchestration is needed. DeMon boots independently and in parallel, making its own decisions without waiting for the FPGA.

T+0ms     Power applied

          Two independent processes begin simultaneously:

          FPGA                            DeMon (RP2350)
          ────────────────────────        ────────────────────────
          Autoloads bitstream from        Boots immediately
          its own SPI flash               Reads RTC → date/time
          No external help needed         Reads FRAM → boot counter
                                          Samples skip key state
                                          Generates RNG seed
                                          Rolls all variant slots
                                          Checks calendar themes
                                          Builds IntroParams struct
                                          Releases SG2000 from reset
                                          ← SG2000 begins booting

T+~5ms    DeMon has IntroParams ready
          Waiting for FireStorm QSPI to come alive

T+~200ms  FireStorm fabric up — EE running from flash
          DeMon hands IntroParams via QSPI immediately

          ╔══════════════════════════════╗
          ║  INTRO BEGINS                ║
          ║  Ball enters screen          ║
          ║  Audio fires on first bounce ║
          ╚══════════════════════════════╝

          Meanwhile, in parallel and invisible:
          ├─ SG2000 has been running since T+~5ms
          │   — nearly 200ms head start already
          ├─ AntOS little core initialising
          ├─ DDR3 training running
          ├─ Filesystems mounting
          ├─ Network stack initialising
          └─ Pulse establishing QSPI connection to FireStorm

T+~5500ms INTRO ENDS — logo locked, final note

          SG2000 has had ~5.3 seconds uncontested boot time

          DeMon checks: is SG2000 ready?
          ├─ YES → seamless cut to AntOS shell
          └─ NO  → EE enters idle loop (logo breathes,
                   ambient audio continues) until ready

The SG2000 is released from reset at T+~5ms — as early as DeMon can act. It does not wait for the FPGA. It does not wait for the intro to begin. There is no reason to hold it. The intro and the OS boot run in parallel from the first moment either can begin.

Why the EE Runs Everything

The intro runs entirely on the FireStorm Execution Engine (EE) and its integrated blitter and DSP subsystems. The SG2000 is not involved. Pulse is not a dependency — if it comes up mid-intro and establishes its QSPI connection, the EE simply hands off sequencer control afterwards. If it doesn't, the intro is unaffected.

This is the right division of labour. The EE runs at the fabric clock rate with direct register access to every blitter sub-unit, the Copper, the layer compositor, the sprite engine, the palette RAM, and the audio DSP. There is no OS, no memory management, no competing processes. A bloom particle list dispatch is a register write sequence, not a system call. Audio note events are triggered by the same physics tick that computes the ball's floor contact — audio and visual are causally linked in a single code path with no inter-processor synchronisation needed.

The SG2000's value is in the high-level application layer: AntOS, the workstation application, the user shell. For five seconds of precisely timed hardware-accelerated graphics and synthesis, the EE is the correct processor by a wide margin.

What DeMon Provides

DeMon's role in the intro is narrow and complete:

• Read the RTC and determine the current date
• Read the boot counter from FRAM and increment it
• Sample the skip key and jog dial states at power-on
• Generate the RNG seed (RTC value + boot counter + hardware entropy source)
• Roll all six variant slots against their weighted tables
• Apply any calendar theme overrides to the rolled slots
• Check boot counter milestone triggers
• Pack everything into the IntroParams struct
• Hand the struct to the EE via QSPI when FireStorm comes up
• Monitor the skip key during playback and signal the EE if pressed
• Poll the SG2000 for readiness and signal the EE when the handoff can occur

// IntroParams — packed into ~16 bytes, passed DeMon → EE via QSPI
typedef struct {
    uint8_t  variant_env;          // 0–7:  environment
    uint8_t  variant_protagonist;  // 0–6:  protagonist
    uint8_t  variant_smash;        // 0–6:  smash behaviour
    uint8_t  variant_reform;       // 0–6:  logo reformation
    uint8_t  variant_audio;        // 0–8:  audio skin
    uint8_t  variant_env_audio;    // 0–6:  environmental DSP preset
    uint8_t  theme_id;             // 0 = none, 1–N = calendar theme
    uint8_t  theme_flags;          // bitmask of theme sub-options
    uint16_t boot_count;           // for milestone triggers
    uint8_t  rng_seed[4];          // for in-EE random sub-variation
    uint8_t  skip_held;            // 1 = skip was held at power-on
    uint8_t  reserved;
} IntroParams;

FPGA Flash Layout

The intro occupies a dedicated 4MB partition of the FPGA's SPI flash, loaded at bitstream startup and mapped into the EE's address space.

FPGA Flash — Intro Partition (4MB)
┌─────────────────────────────────────────────────────────────┐
│  EE Bytecode                                                │
│  ├─ main.ee              top-level sequencer                │
│  ├─ physics.ee           ball / particle physics            │
│  ├─ variants/            one module per variant slot        │
│  │   ├─ env_space.ee                                        │
│  │   ├─ env_underwater.ee                                   │
│  │   ├─ env_maze.ee                                         │
│  │   ├─ smash_wall.ee                                       │
│  │   ├─ smash_fireworks.ee                                  │
│  │   ├─ reform_magnetic.ee                                  │
│  │   ├─ reform_sdf_morph.ee                                 │
│  │   └─ ...                                                 │
│  ├─ themes/              calendar theme overlays            │
│  │   ├─ christmas.ee                                        │
│  │   ├─ bonfire_night.ee                                    │
│  │   ├─ halloween.ee                                        │
│  │   └─ ...                                                 │
│  └─ effects/             reusable effect modules            │
│      ├─ snowfall.ee                                         │
│      ├─ fireworks.ee                                        │
│      ├─ aurora.ee                                           │
│      └─ ...                                                 │
│                                                             │
│  Asset Data                                                 │
│  ├─ HAM24 backgrounds (nebula, underwater)     ~608 KB      │
│  ├─ Maze cell map + wall textures               ~34 KB      │
│  ├─ Zodiac animal vector paths (×12)             ~2.4 KB    │
│  ├─ Audio note/step sequences (all variants)       ~4 KB     │
│  ├─ Calendar lookup tables (20 years)            ~12 KB     │
│  ├─ Petal / leaf quad textures                   ~1 KB      │
│  └─ Misc LUTs, Copper lists, theme assets        ~30 KB     │
│                                                             │
│  TOTAL USED:  ~890 KB                                       │
│  RESERVE:     ~3.3 MB                                       │
└─────────────────────────────────────────────────────────────┘

Nearly all visual content is procedurally computed — the checker pattern on the Boing Ball is generated mathematically from rotation state per frame, the starfield from a hash function on pixel coordinates, particle physics from Newtonian equations. The flash stores EE bytecode, a handful of HAM24 photographic backgrounds, and lookup tables. The hardware does everything else.

Audio note and step sequences live in flash alongside the EE bytecode. Patch and instrument data — synthesis voice parameters, wavetables, FM operator configurations, sample data — live in the audio system's own flash partition, shared with the workstation app and sequencer. The synthesis itself runs entirely in FireStorm's DSP pipeline — no pre-rendered audio anywhere. Every sound is computed in real time by the voice engine; the intro simply references the patches that already exist in the audio partition.

Fault Tolerance

The architecture degrades gracefully at every stage:

• Pulse not ready — the intro neither knows nor cares. Audio runs on FireStorm DSP directly. If Pulse comes up mid-intro, the EE hands off sequencer control afterwards.
• SG2000 slow to boot — the EE enters the idle loop. The logo breathes gently, ambient audio continues. The user assumes the intro is still playing.
• RTC unavailable (flat battery, first boot) — DeMon sends a zero-date IntroParams. The EE runs the non-themed base variant pool. No error, no crash.
• FPGA bitstream corruption — DeMon detects no QSPI handshake within its timeout window and can signal a fault condition. The intro simply does not play; the machine boots to a fallback state.

Because the intro runs from read-only FPGA flash below the software line entirely, a corrupt AntOS filesystem, a failed startup script, or broken user configuration cannot affect it. The machine always boots beautifully regardless of software state.

The Sequence

Structure

Every boot plays a sequence of approximately 5–6 seconds consisting of five phases:

Phase 1 — Entry (~2–3s) The protagonist enters the scene and bounces. Each bounce sounds and feels physically correct — squash and stretch, a shadow tracking altitude, the characteristic rotation of the Boing Ball's checker pattern. Three to four bounces, building anticipation. On the final approach, the trajectory aims for a wall.

Phase 2 — The Smash (~0.3s) Impact. The protagonist shatters. The audio hit is percussive and immediate, matched to the frame of contact. FireStorm's blitter launches the particle system — 40 to 200 particles depending on variant, each a bloom-lit quad with initial velocity, spin, and colour derived from the protagonist's surface.

Phase 3 — The Hang (~0.5s) Particles slow. The chaos settles. A beat of near-stillness before the pull begins.

Phase 4 — The Reformation (~1.5–2s) Particles are drawn inward toward the Ant64 logo's geometry. The specific path they take depends on the reformation variant. The audio builds underneath — the jingle's main phrase rising as the logo assembles.

Phase 5 — The Lock (~1s) The final particles click into place. The logo holds clean. The jingle's final note blooms. A brief hold, then the cut to AntOS.

The Skip Mechanism

If the user holds a designated key or jog dial push at power-on, DeMon sets skip_held = 1 in IntroParams. The EE checks this on startup and jumps directly to the OS handoff. DeMon continues monitoring during playback — a skip signal mid-sequence triggers an immediate graceful cut.

The Six Variant Slots

Each slot rolls independently from a weighted table. Combined they define the unique character of each boot. Between them, across enough variants, the full capability of the display system, blitter, and audio system is demonstrated — no two variants showcasing the same technique.

Slot 1 — Environment

The scene behind the protagonist. Rolls once per boot. Technically the most diverse slot — each option demonstrates a different rendering approach.

The maze variant uses FireStorm's dedicated ray cast hardware — the same DDA units documented in the display system section. At Standard resolution the unit pool casts all 480 columns simultaneously. The wall textures are the Boing Ball checker pattern, tying the maze visually to the protagonist it leads toward.

Slot 2 — Protagonist

What bounces. The Boing Ball in its original form is the most common result but far from the only option.

The Fuji variant deserves special mention. The Atari Fuji logo begins assembling from the screen edges — geometric vectors constructing it in real time using blit.line_bloom — and gets to perhaps 80% complete before the Boing Ball smashes in from off-screen at speed and obliterates it. The Fuji fragments join the particle cloud and the Ant64 logo reforms from the combined wreckage. Affectionate, not hostile.

Slot 3 — Smash Behaviour

What happens at the moment of impact. The audio hit is always present; the visual varies considerably.

The slow motion variant gets the highest particle count precisely because the time budget is relaxed. 200 particles with full bloom falloff, sub-frame motion blur on the tumbling fragments, the checker surface breaking apart in UV-correct pieces. It is the most expensive frame in the entire intro and looks it.

Slot 4 — Logo Reformation

How the Ant64 logo assembles from the particle cloud.

The SDF morph is the most technically distinctive. The protagonist and the Ant64 logo are both represented as signed distance fields. Between smash and lock the EE ray-marches a linearly interpolated blend of the two — the ball's sphere geometry smoothly deforming into the logo's flat geometry over approximately 90 frames. No particles. Just mathematics.

Slot 5 — Audio Skin

Which synthesis approach the jingle takes. All options use FireStorm's DSP voice pipeline directly — no samples, no pre-rendered audio. Every sound is computed in real time from patch parameters stored in a few hundred bytes each.

Patch and instrument data for all variants lives in the audio system's flash partition, shared with the workstation app and sequencer. The intro stores only the note and step sequences that drive those patches — typically 50–400 bytes per variant.

The orchestral variant uses 40+ simultaneous VA voices, the FDN 8-line reverb at maximum hall size, and the full BBD chorus on the string layer. It is the most computationally expensive audio option in the intro — and audibly so.

The 303 variant triggers the dedicated TB-303 engine described in the audio system documentation: dual envelope generators, the accent accumulation circuit, the diode ladder filter with its characteristic non-self-oscillating overdrive. The acid riff runs for the duration of the protagonist's bounces and is cut by the smash impact.

Instrument and patch data — synthesis voice parameters, wavetables, FM operator configurations, sample data — are not part of the intro flash partition. They reside in the audio system's own flash region, shared with the workstation app, sequencer, and all other audio consumers. The intro references them at playback time. Only note sequences, MOD pattern data, and augmentation mapping tables are stored in the intro partition.

Slot 6 — Environmental Audio Processing

Applied to the audio output using FireStorm's built-in environmental DSP presets. These are register writes only — no additional compute cost beyond the effect pipeline already present.

Notable Combinations

Certain pairings will earn names among owners:

The Classic — Standard Ball / Void / Wall Smash / Magnetic Pull / FM Bell / Dry
The baseline. Every other variant is implicitly measured against this one.

The Deep — Ball / HAM24 Underwater / Floor Impact / Particles float upward / VA+BBD / Underwater DSP
The ball drifts in, neutrally buoyant. Hits the floor. The smash is a soft impact sending particles rising. Audio: the jingle heard through pressure and slow chorus, the underwater environmental DSP applied to everything. The only stored asset is the HAM24 background.

The Void — Ball / Space Starfield / Off-screen Smash / Orbit then Spiral / Granular Sub-bass / Dry or 10s Reverb
Silence and space. Starfield parallax behind particle orbits. Zero asset storage beyond the starfield code.

The Interloper — Fuji Assembling / Black Void / Ball smashes in and destroys Fuji / SDF Morph / 303 Acid Riff / Dry
The 303 acid riff starts as the Fuji begins constructing. Gets cut off by the smash. The Ant64 logo SDF-morphs from the combined wreckage of Fuji and ball.

The Machine — Standard Ball / Tron Grid / Slow Motion Smash / Bloom Wire-Build / Orchestral VA Swell / Hall FDN
Ball on a Copper-driven Mode 7 perspective floor. The slow motion smash at 200 particles. Logo assembling as progressive bloom line geometry. Forty-voice orchestral swell in a large FDN hall. The most technically diverse single combination.

The Maze Runner — No Ball / First-Person Maze / Crash Into Logo / Scanline Reveal / Footstep SFX / Cavern DSP
Hardware DDA ray cast units doing their documented job. Footstep SFX panning with camera X turn. Cavern environmental DSP giving corridor echo. Only stored assets are the 34KB cell map and wall textures.

The Ghost — CRT Room / Ball with CRT Simulation / Phase-Through Smash / Particles Reveal Pre-existing Logo / Almost Silent / Damaged Audio
The ball phases through the wall via Copper scanline glitch. The logo was always there — just hidden. Near-silence makes it unsettling. The CRT simulation pipeline is live on the ball's layer as an independent effect.

The Rarity — Two Balls / HAM24 Nebula / Mid-Air Collision / Double Particle Burst / SID Chiptune / Dry
HAM24 nebula behind two balls drifting toward each other. The SID chiptune — VA engine emulating three-channel SID character — plays until the collision kills it and the jingle restores from the cloud.

The State of the Art — Rotoscope Environment / Boing Ball / Wall Smash / Magnetic Pull / MOD track → Full Synth handoff / Hall FDN
A figure dances in silhouette against near-darkness, lit by the bounce of the ball, while a rave MOD track plays live from the EE. The ball enters the scene, bounces once off the dancer's shadow, smashes, and the particle reformation assembles the logo as the MOD's final bar resolves into the full VA synthesis arrangement. Anyone who was there in 1992 will know exactly what this is a reference to — and immediately notice how far beyond it the hardware goes.

The Reveal — Old Skool Prologue Wrapper / Any Protagonist / Any Smash / Any Reformation / SID evolving to full synth / Dry
The sequence opens as a faithful Atari/Amiga-era demo — copper rainbow bars, bobs, a sine wave scroller, palette cycling, a flat chunky starfield. Exactly as 1989 looked. Then something starts to feel wrong. The colours gain more depth than they should. The bobs start casting light on each other. The starfield acquires parallax layers. The bars develop bloom. The audio adds voices that no SID chip ever had. By the time the ball enters the scene the transformation is complete — everything looks and sounds contemporary, and the viewer has just watched 35 years of hardware evolution compressed into two seconds. The Copper did it all. It never stopped — it just got more ambitious.

The State of the Art Variant

Concept

In 1992 the Amiga demo group Spaceballs released State of the Art — a demo whose central visual was rotoscoped footage of a dancer, rendered in a limited palette at low resolution, playing against a dark background while a rave track drove the tempo. It was jaw-dropping not because the technology was complex but because nobody had thought to put those specific things together in that specific way. The figure moved with human fluency that no procedural animation of the era could match. The music was something you would have heard at a rave the previous weekend.

The Ant64 variant is a direct homage and a direct continuation. The same creative idea — rotoscoped human movement, rave music, bold limited-palette visuals — applied to hardware that is several orders of magnitude more capable, with a production pipeline the original team could not have imagined. Where State of the Art was constrained by what an Amiga 500 could do, the Ant64 version is constrained only by what fits in 4MB of flash — and that turns out to be quite a lot.

The two technical pillars of the variant are entirely independent of the SG2000 and Pulse: the rotoscoped animation is EE-driven sprite playback from flash assets, and the music is a MOD track played by a lightweight MOD player running as an EE scheduled task, driving the FireStorm audio DSP voice registers directly.

AI-Generated Rotoscope Assets

From Pixels to Geometry

The naive approach to rotoscoped animation is pixel delta compression — store the difference between consecutive frames as a run-length encoded bitmap. At 128×160 pixels, 4bpp, delta-compressed, a 5-second sequence costs roughly 640KB. That is workable, but it treats the figure as a texture to be played back. It cannot respond to the scene, deform to the music, morph into another shape, or act as a stencil for other effects.

The better approach is to store the figure as geometry — a vector contour path representing its silhouette at each keyframe — and let the EE and blitter render it in real time. A vector path for a human figure at a keyframe requires approximately 60–120 control points. At 2 bytes each, delta-encoded from the previous keyframe, that is 200–400 bytes per frame. A full 5-second sequence at 25 keyframes per second drops from ~640KB to roughly 24KB. The entire rotoscope library that previously threatened to overflow 4MB now fits in the original budget with room to spare.

The real gains are not storage. They are what geometry enables that pixels cannot.

What Vector Figures Enable

Fill effects and stenciling — the figure outline becomes a clip region. The FireStorm clip table system accepts per-scanline left/right span boundaries, which is precisely what a filled vector contour produces. Feed the figure's scanline spans into the clip table and any layer effect — any layer in the entire compositor — is masked to the figure's silhouette:

• The starfield: the dancer is a window into space, stars visible only through the body
• The HAM24 nebula: colour and light moving inside the figure's outline
• The Copper rainbow bars: bars visible only where the figure stands
• A bloom particle volume: the figure's interior is filled with glowing particles that move with the music
• The aurora: cold light rippling through the body
• A fire column: the dancer burning, flames constrained to the silhouette
• Any combination of the above composited as independent layers

Resolution independence — vector geometry scales to any native resolution without quality loss. The same contour data renders at 320×180 or 960×540 with identical precision. Pixel assets require separate storage per resolution.

Continuous interpolation between keyframes — vector paths have explicit semantic structure that pixel frames do not. Control point N in keyframe A and control point N in keyframe B represent the same point on the figure's outline at two moments in time — because the AI pipeline normalised them to correspondence during asset creation. Interpolating between them at parameter t is a single multiply-add per control point:

point(t) = keyframe_A[N] × (1 - t) + keyframe_B[N] × t

The resulting path is geometrically correct at every intermediate frame. The shoulder is between its two positions. The hand arc follows a straight line through space between its two poses. No optical flow estimation, no crossfade artefacts, no ambiguity about what corresponds to what. Two pixel frames interpolated produce transparency, not motion. Two vector paths interpolated produce the actual in-between pose.

The keyframe data can be captured at whatever rate the motion requires — typically 12fps for slow expressive movement, 25fps for fast limb action. The output always runs at the display frame rate (60fps, or higher under VRR) because the tween is pure arithmetic, not stored data. Motion is smooth at 60fps from 12fps source keyframes.

Morphing between different figures — the dancer, the Boing Ball, and the Ant64 logo are all closed vector paths. If they share the same control point count, the same tween function that smooths animation between keyframes also morphs one figure into another. At t=0.0 you have the dancer. At t=1.0 you have the logo. At t=0.5 you have a geometrically valid intermediate shape that the rasteriser can fill and apply effects to — it looks intentional rather than broken, because it is a real contour at every interpolated value. No special-case morph code. The same multiply-add per point, the same EE function, a different pair of input paths.

This universality is a direct consequence of the representation. Once the system commits to storing all animated shapes as normalised control point paths, every shape can transition into every other shape. The tween infrastructure pays for itself across the entire intro system — figure animation, figure-to-logo reformation, bob-to-sphere transition in the old skool variant, and any future shape added to the asset library.

The logo reformation as a figure morph — if the Ant64 logo is stored as a vector path with the same control point count as the dancer, the particle reformation phase can be replaced with a direct geometric morph: the dancer's body literally reshapes itself into the Ant64 logo over 60 frames of smooth interpolation. No particles. Pure geometry transitioning between two human-readable shapes at 60fps, each intermediate frame a valid filled contour that can carry any fill effect — the aurora, the starfield, the particle volume — right through the transition. The fill does not know or care whether the outline it is filling is a person or a logo. It just fills the current path. This is an entirely new kind of sequence ending that no pixel approach can produce.

The normalisation step in the AI pipeline — ensuring the dancer path and the logo path have the same control point count with stable correspondence — is what makes this possible. It is the most important single operation in the asset creation process, and it needs to be done once, offline, at authoring time.

Audio-reactive deformation — once the figure is geometry, the EE can deform its control points in real time. A bass-frequency bulge on the beat. Ripple distortion propagating from the smash impact point across the figure's outline. Gravity sag when a particle cloud hits. The figure responds to the scene rather than playing back indifferently against it.

The AI Pipeline

The pipeline targets vector contour extraction rather than pixel stylisation:

Reference footage (synthetic 3D or live action)
    │
    ▼
AI contour extraction
    ├─ Per-frame silhouette mask generation
    ├─ Contour tracing → raw polygon (500+ points)
    ├─ Path simplification (Ramer-Douglas-Peucker)
    │   → reduces to 60–120 control points
    ├─ Control point count normalisation
    │   → same count across ALL frames AND all figures
    │     (dancer, ball, logo — all share the same N)
    │   → correspondence determines which point on A
    │     maps to which point on B during morph
    │   → most critical step in the entire pipeline
    └─ Temporal smoothing
         → prevents control point jumping between frames
    │
    ▼
Keyframe selection
    ├─ Full pose stored at significant motion events
    │   (peak of gesture, moment of stillness, beat accent)
    ├─ Keyframe rate chosen per sequence:
    │   12fps for slow / expressive movement
    │   25fps for fast limb action
    ├─ Output always at display frame rate (60fps+)
    │   — tween is arithmetic, not data, costs nothing extra
    └─ Intermediate frames computed by EE each output frame
    │
    ▼
Compact binary encoding
    ├─ Control points as S12.4 fixed-point
    ├─ Delta-encoded from previous keyframe
    ├─ ~96 control points × 2 bytes = ~192 bytes/keyframe
    ├─ 125 keyframes (5 seconds × 25fps) = ~24 KB total
    └─ Optional: precomputed scanline span table
         (+~400 bytes/keyframe, zero rasterise cost at runtime)
    │
    ▼
Flash asset pack
    └─ Keyframe table + control point data (+ optional spans)

The AI contour extraction step can use open-source segmentation models (SAM, Segment Anything, similar) to generate per-frame silhouette masks from the reference footage, followed by standard computational geometry for contour tracing and simplification. The normalisation step — ensuring consistent control point count and correspondence across frames — is the most critical and least trivial part of the pipeline, but is a solved problem in the mesh morphing literature.

The development toolchain includes a conversion utility that runs the full pipeline from source footage to flash asset, reports storage cost and worst-case EE rasterise time per frame, and validates that control point correspondence is stable across the full sequence.

The Scanline Span Cache

The EE must rasterise the filled vector contour to a per-scanline span table before the clip table system can use it. For a figure spanning approximately 200 active scanlines this means computing left/right boundaries for each scanline — a few thousand multiply-adds per frame, well within the EE's cycle budget at 200MHz for interpolated in-between frames.

For stored keyframes the spans can be precomputed at packing time and stored alongside the control points — trading approximately 400 bytes per keyframe for zero rasterisation cost at runtime. Whether to precompute or compute live is a per-sequence choice based on available flash headroom and EE load profile.

Storage Characteristics

Control points per keyframe:       ~96 × 2 bytes      =   ~192 bytes
Optional span cache per keyframe:                      =   ~400 bytes

At 25fps keyframe rate (fast movement):
  Keyframes (5 sec):   125
  Raw data:            125 × 192                       =    24 KB
  With span cache:     125 × 592                       =    74 KB

At 12fps keyframe rate (slow / expressive movement):
  Keyframes (5 sec):   60
  Raw data:            60 × 192                        =    11.5 KB
  With span cache:     60 × 592                        =    35 KB

Output frame rate: always 60fps (or display VRR rate)
Tween algorithm:   EE computes fractional blend each output frame
                   — arithmetic only, no additional stored data

The keyframe rate is chosen per sequence at pipeline time based on motion complexity. A rave dancer with fast arm and leg movement warrants 25fps keyframes. A slow Bharatanatyam gesture or a conductor's arc can be fully represented at 12fps. The output is indistinguishable in both cases — 60fps smooth motion either way.

A full library of animation sequences at 74KB each fits many dozens into the 4MB flash partition. The pixel approach required ~640KB per sequence — a 9× improvement with the span cache included, 27× without it.

Multiple Sequences and Fill Variants

Because the figure is geometry, the same stored sequence can be rendered with completely different visual results by changing what fills it. The AI pipeline generates the figure once; the fill effect is chosen at runtime from whatever the other variant slots have rolled:

The fill effect is not stored with the sequence. It is selected by the variant roll and rendered by the FireStorm compositor at boot time. The same dancer geometry serves completely different aesthetics depending on which layer is fed through the clip table that frame.

The EE MOD Player

Overview

A lightweight ProTracker MOD player runs as a scheduled task in the FireStorm EE. It reads a MOD file from flash, maintains pattern and position state, processes effects on each tick, and writes note events directly to the FireStorm audio DSP voice registers via standard register writes. No Pulse involvement. No SG2000 involvement. The entire music playback system is self-contained within the EE and the audio DSP pipeline that is already running as part of FireStorm.

This is the correct architecture for the intro: the MOD player is one more EE task alongside the physics update, the Copper list generation, and the blitter job dispatch. It fires on a precise tick schedule, writes a small number of registers, and yields. The audio DSP voices handle the rest autonomously at sample rate.

MOD Format

The classic ProTracker MOD format is compact and well-documented:

MOD File Layout
├─ Song title (20 bytes)
├─ 31 instrument headers × 30 bytes each
│   ├─ Name (22 bytes)
│   ├─ Sample length in words (2 bytes)
│   ├─ Finetune value (1 byte)
│   ├─ Volume 0–64 (1 byte)
│   ├─ Repeat offset in words (2 bytes)
│   └─ Repeat length in words (2 bytes)
├─ Song length (1 byte) — number of patterns in order
├─ Restart position (1 byte)
├─ Pattern order table (128 bytes)
├─ Format tag "M.K." or "FLT4" (4 bytes)
├─ Pattern data: 64 rows × 4 channels × 4 bytes per note
│   └─ Each note: instrument, period (frequency), effect command + parameter
└─ Sample data: raw 8-bit signed PCM, concatenated

A typical 4-channel rave MOD with rave-era samples — piano stab, hoover, kick, snare, hi-hat, bassline — runs to approximately 200–400KB depending on sample length. This fits comfortably within the flash budget alongside the rotoscope animation data.

Tick Scheduler and Effect Processing

The ProTracker timing model:

BPM = 125 (default, adjustable via Fxx effect)
Ticks per row = 6 (default, adjustable via Fxx)
Tick rate = BPM × ticks_per_row / 2.5 = 300 ticks/second
Tick interval = 1 / 300 = 3.33ms = ~667 fabric clock cycles at 200MHz

The EE task scheduler fires the MOD tick handler every 667 cycles (at 200MHz fabric clock). This is a short, bounded task: check if this tick begins a new pattern row, parse the row's four note slots, process effects, write changed voice registers. On a new-note tick the work is slightly more — load sample address, set period and volume. On intermediate ticks only active effects update. Total EE cycles per tick is well under 100 for a standard 4-channel MOD — a rounding error on the available budget.

Effects implemented (initial set):

This covers the vast majority of effects used in rave-era MODs. Extended effects (E-commands beyond finetune) can be added incrementally as specific tracks require them.

Sample Playback via FireStorm DSP

Each of the four MOD channels maps to one FireStorm sample playback voice. The MOD player writes to these voice registers on each new note:

// Per new note event — EE register writes to audio DSP:
voice[ch].sample_base  = sample_data_address_in_gfx_sram;
voice[ch].sample_len   = instrument.length_words * 2;
voice[ch].loop_start   = instrument.repeat_offset * 2;
voice[ch].loop_len     = instrument.repeat_length * 2;
voice[ch].playback_hz  = AMIGA_CLOCK / period_value;
voice[ch].volume       = note_volume;  // 0–64
voice[ch].trigger      = 1;            // fires the voice

The FireStorm sample engine handles the rest: interpolated playback at the correct pitch, loop point management, volume envelope. The 8-bit signed PCM samples are loaded into Graphics SRAM at EE startup from the audio system's flash partition — the same partition used by the workstation app and sample engine. They are not duplicated in the intro partition. The intro partition stores only the MOD pattern and order data; the instrument sample data belongs to the audio system.

Loop handling matches the ProTracker model exactly: if repeat_length > 1, the voice loops between loop_start and loop_start + loop_len indefinitely until a new note fires on that channel.

FPGA Synthesis Augmentation

The MOD player drives the four sample playback voices. But the FireStorm audio DSP has 128+ voices available — the sample channels consume four of them. The remaining voices can be used to augment specific instruments with native FPGA synthesis, layered transparently under the MOD playback:

The hoover augmentation is the most significant. When channel N triggers the hoover sample, the EE also fires the M-86 VA synthesis patch — PWM sawtooth oscillators, fast LFO on PWM, BBD chorus, dropping pitch envelope — on a parallel synthesis voice at the same pitch. The synthesised hoover plays blended with the sampled one. The result has the organic quality of a real sample and the depth and movement of full synthesis simultaneously. It sounds like a 1992 rave record played back through hardware that didn't exist in 1992.

Bass augmentation: when the MOD's bass channel fires a low note, a sub-octave VA sine wave voice can be added underneath — filling out the low frequencies that 8-bit samples at MOD resolution cannot capture cleanly.

Kick augmentation: the sampled kick can be paired with a short synthesised click and sub-bass thud from the SFX engine, giving it more physical impact than the sample alone.

The augmentation mapping is stored in a small table alongside the MOD file — a few bytes per instrument slot indicating which synthesis patch (if any) should fire in parallel. This table is authored once per MOD track and stored in flash with it.

The MOD Track Selection

The intro pool contains a small library of rave-era MOD tracks. Appropriate tracks are freely available from the Mod Archive and similar repositories, licensed for non-commercial use. The selection criteria:

• 4-channel ProTracker format (simplest player implementation)
• Rave / house / techno aesthetic — 1992–1995 era
• Contains a hoover, a piano stab, or another instrument the FPGA synthesis can augment
• Total file size under 400KB to fit alongside the rotoscope animation data
• Loopable: the track should feel natural at any point the intro cuts away from it

The specific track can roll randomly from the pool, independent of the other variant slots. Different boots play different tracks, giving the State of the Art variant its own internal variation system.

The MOD–Visual Synchronisation

The MOD player knows the exact tick position at all times. The EE uses this to synchronise visual events to musical events:

• Ball bounce timing: the ball's entry is delayed or accelerated slightly to land its first bounce on a beat boundary. The physics simulation runs slightly fast or slow for the first 0.5 seconds to phase-lock the bounce to the kick drum. The timing adjustment is small enough to be imperceptible as a physics anomaly but produces a satisfying impact-on-beat that feels composed rather than coincidental.

• Copper palette to music: the Copper cycles the figure's edge-glow palette colour in sync with the MOD's tick counter — brightening on beats, dimming between them. The figure pulses with the music.

• Smash on bar boundary: the smash is triggered not when the ball reaches the wall but when it is close enough and a bar boundary is approaching. The EE holds the ball at near-wall position for up to one bar length (at 125 BPM that is 1.92 seconds maximum) and fires the smash exactly on the downbeat. The musical impact and the visual impact are the same event.

• MOD fade on logo lock: as the logo assembles, the MOD volume slides down over 8 bars via a software-driven volume slide on all channels. The chosen audio skin's jingle fades up simultaneously. The handoff between the rave track and the logo jingle is a crossfade timed to the bar length.

The Sequence in Full

T+0ms (from intro start)

    Background: near-dark. A faint low-frequency pulse from the MOD's kick
    drum. The rotoscope figure is not yet visible.

T+~200ms

    The MOD track has established its groove — kick, bass, hi-hat pattern
    recognisable. The figure appears from the bottom of frame, rising into
    visibility as the next phrase begins. The Copper pulses the figure's
    edge glow with the beat.

T+~800ms

    The Boing Ball enters from the upper-left on its standard arc. The ball
    is phase-locked to the MOD — its first bounce lands on a beat.

T+~1200ms

    The ball and figure interact: the ball's bounce shadow crosses the
    figure's feet. The figure's movement is choreographed to step aside
    slightly as the ball passes — the rotoscope sequence includes this
    interaction beat, authored into the animation at pipeline time.

T+~2000ms

    The ball makes its final approach. It is near the wall. The EE holds
    it there, waiting for the bar boundary.

T+~2400ms  (downbeat of new bar)

    SMASH. The ball hits exactly on the one. The particle explosion fires.
    The MOD's snare fires on the same tick. The kick fires. The hoover
    augmentation voice sweeps upward over the smash debris. The figure
    reacts — the next rotoscope frames show the figure recoiling from the
    impact, particles passing through and around the sprite.

T+~3000ms

    Particles begin converging. The figure has stepped back, partially
    obscured by the particle cloud. The MOD continues — now slightly softer,
    volume sliding down under EE control. The jingle begins to emerge from
    underneath.

T+~4500ms

    Logo locked. MOD has faded to silence. The jingle's final chord holds.
    The figure has exited frame downward — the last rotoscope frames show
    the figure stepping out of view as the logo takes the stage.

T+~5500ms

    Cut to AntOS.

Extending the Concept — More Rotoscoped Variants

The rotoscope pipeline is not limited to the State of the Art variant. Once the AI generation and compression toolchain exists, the same pipeline can produce assets for other intro contexts:

The Maestro — a conductor figure, arms moving in time with the orchestral VA swell audio variant. The conducting gesture and the music phrase are synchronised at authoring time.

The Coder — a silhouetted figure at a keyboard, the typing rhythm driving the Programmer's Day (September 13) calendar theme. Fingers moving. Screen glow on the figure's face suggested by Copper-driven palette animation.

The Dancer (Diwali variant) — a Bharatanatyam gesture sequence, warm amber palette, diya candles framing the figure. The AI pipeline generates this from reference footage of the specific gesture vocabulary.

The Astronaut — a figure in a pressure suit, slowly floating, for the space environment variant. Movements that suggest zero gravity — achieved in the animation by simply making all movements slow and show no weight.

Each of these is a separate AI pipeline run producing a ~640KB flash asset. Each adds a new dimension of human presence to the intro system — something no purely procedural effect can provide.

Storage Impact

The vector geometry approach transforms the storage picture relative to a pixel-based implementation. Figures stored as interpolatable control point paths rather than compressed pixel deltas cost roughly 27× less per sequence:

MOD pattern + order data (4–6 tracks):              ~24 KB
  (instrument sample data lives in audio partition,
   not charged to intro budget)
Rotoscope sequence — rave dancer standard:             ~74 KB
Rotoscope sequence — alternate choreography:           ~74 KB
Rotoscope sequence — abstract / geometric:             ~40 KB
Rotoscope sequence — slow / meditative (Vesak):        ~60 KB
Rotoscope sequence — two figures mirrored:            ~120 KB
Rotoscope seasonal variants (×3, various):            ~200 KB
MOD augmentation tables (per track):                    ~1 KB
──────────────────────────────────────────────────────────────
TOTAL NEW STORAGE FOR ROTOSCOPE + MOD SYSTEM:         ~397 KB

Combined with the base asset allocation of ~829KB, total flash usage is approximately 1,226KB — well under 30% of the 4MB partition. The flash size does not need to change. The remaining ~2.97MB accommodates further rotoscope sequences, additional MOD tracks, and future variants.

Instrument and sample data for the MOD tracks and synthesis augmentation live in the audio system's own flash partition — shared with the workstation app and sequencer — and are not charged to the intro budget. The intro partition stores only pattern data, note sequences, and augmentation mapping tables. Fill effects are rendered at runtime by the FireStorm compositor and contribute no storage cost.

The Old Skool Transition

Concept

The Copper is a direct spiritual descendant of the Amiga's Copper coprocessor — a general register-write engine that fires at any horizontal or vertical beam position. The Amiga Copper produced the defining visual vocabulary of late 1980s home computing: rainbow gradient bars, colour-cycling palettes, per-scanline horizontal scroll for sine wave effects, raster splits that made the hardware appear to do things it technically could not.

The Ant64 Copper can do all of those things. But it can also drive bloom pre-pass intensity per scanline, switch HAM24 colour space mid-frame, modulate volumetric light shaft density, and crossfade between CRT simulation profiles in real time. It is the same mechanism. The register targets are just considerably more interesting now.

The old skool transition uses this directly. The Copper command list for the prologue phase and the Copper command list for the modern phase are the same structural shape — the same firing pattern, the same scanline cadence — but the registers they write, and the values they write to them, evolve over time. The visual transformation from vintage to contemporary is the Copper becoming progressively more ambitious about what it asks of the hardware it controls.

No mode switch. No cut. The same beam. The same list. Just different registers.

Phase 1 — Old Skool (~1.5s)

The sequence opens with effects that would have been recognisable on any Atari ST or Amiga in 1989. They are rendered authentically — not simulated, not nostalgic approximations, but the actual technique executed by the actual hardware mechanism that the Amiga used.

Copper Rainbow Bars The Copper fires a new background colour register write on every scanline, cycling through a sine-modulated hue gradient. The result is horizontal colour bands sweeping slowly down the screen — the defining visual of a thousand Amiga demos. On the Ant64 the bars are pixel-perfect because the Copper fires at the same precision it always did. The difference from 1989 is that the Ant64 has 24-bit colour versus the Amiga's 12-bit — the gradient is richer — but the mechanism is identical.

The gradient phase advances each frame, making the bars flow. The speed and direction roll randomly per boot — some boots have the bars flowing downward, some upward, some pulsing in and out.

Bobs Overlapping coloured circles — the classic bob effect. Each bob is a filled circle blitted at a position on a Lissajous path, additive-blended, 8–16 simultaneous bobs. The colours are drawn from a limited palette (16 entries, as the era demanded). Where bobs overlap the colours simply add — original hardware behaviour and the blitter's BLT_ADDITIVE flag are doing exactly the same thing for exactly the same reason.

Positions are driven by integer sine table lookups — fixed-point, the same maths a demo coder would have written in 68000 assembly in 1990.

Horizontal Sine Scroller A single line of large text scrolled horizontally with a vertical sine displacement applied per-character via the Copper's per-scanline H_scroll register. The classic wobbly scroller, period-accurate.

The text is chosen at random from a small pool. Options include era-appropriate content — GREETINGS TO ALL AMIGA OWNERS, CODED IN 68000 ASSEMBLY BY THE BEST — and ones that hint at what is about to happen — THIS HARDWARE IS CONSIDERABLY MORE CAPABLE THAN IT APPEARS. The font is a chunky 16×16 bitmap (~512 bytes stored). The sine displacement table is a few hundred bytes of fixed-point values.

Palette Cycling The Copper writes new values to palette registers on a per-frame cadence, cycling colours through a predefined sequence. On the Amiga this animated fire, water, and gradient effects without touching the framebuffer. On the Ant64 it is identical — the palette descriptor system allows any colour to change on any frame at zero framebuffer cost.

Flat Starfield A two-layer starfield with no parallax, limited to the same 16-colour palette as the bobs. Stars are single pixels, no bloom, no depth. Exactly as a real demo would have rendered them given the hardware constraints of 1989.

Audio — Phase 1 The SID chiptune variant plays. Three channels: square wave bass, pulse wave lead, noise-based percussion. A short looping riff in the 4-bar tracker tradition, at 125 BPM — the ProTracker default. The VA engine constrains itself deliberately: no more than 3 voices active, no reverb, no BBD chorus, no effects processing. It sounds like 1989 because it is choosing to.

The Transition (~0.5s)

The shift is not announced. It begins subtly and accelerates.

The rainbow bars are still present — but their gradient now has more colour steps than a 12-bit palette could hold. The banding between colours smooths imperceptibly at first.

The bobs begin casting a soft glow onto the surfaces behind them. They were flat before. The bloom pre-pass is now firing on the same scanlines as the Copper colour writes — the same registers, the same timing, one additional write per scanline.

The flat two-layer starfield acquires a third layer, then a fourth. Stars gain a one-pixel bloom halo. Parallax deepens. The sense of depth grows from nothing to convincing in approximately 20 frames.

The Copper now writes to the bloom intensity register on each scanline alongside the background colour. The bars develop glow. HDR values begin exceeding the old palette ceiling. The bars start to look less like raster splits and more like volumetric light shafts. They always were the Copper writing colour registers on scanline boundaries. Now the colour registers go to a different place.

The bobs are no longer flat circles. The blitter draws them with a specular highlight map and a physically plausible falloff. They have become spheres — the same Lissajous positions, the same additive blend — but lit objects rather than coloured discs. The transition from bob to sphere happens over approximately 15 frames with no visible seam.

The scroller text fades. The characters dissolve into particles — the same particle system the ball smash uses — and drift upward out of frame. This is the first moment that is clearly impossible on period hardware, and it happens last deliberately: everything before it could have been a very good Amiga demo. This cannot.

Audio — transition The three SID-constrained channels begin acquiring voices. A fourth enters — still in character with the chiptune, but with an FM timbre that no SID chip could produce. Then a fifth. The bass gains the BBD chorus — the defining sound of the Roland Juno, unmistakably not a chip synthesiser. By the end of the transition the audio has grown from 3 voices to 12, from a 3-channel chiptune to a layered synth arrangement, without any audible break in the musical phrase. The note sequence was always the same. The voices behind it just kept arriving.

Phase 2 — Full Modern (~ongoing into main sequence)

The transition completes. What remains is the full Ant64 rendering environment:

• Multi-layer parallax starfield with depth-of-field bloom on distant stars
• Per-pixel lit spheres with specular reflections where the flat bobs were — or the bobs dissolving entirely as the protagonist ball enters from the wings
• Volumetric light shafts where the Copper bar positions were, rendered with full bloom and atmospheric scattering
• The chosen environment — HAM24 background, maze, Tron grid, or other — loading in behind the now-modern scene as the prologue clears
• Audio at full voice count, full effects chain, the chosen audio skin now in effect

The Boing Ball enters into this transformed scene. Everything from this point follows the normal sequence — bounce, smash, particle reformation, logo lock. But the viewer has just watched the evolution happen live.

The Prologue Wrapper

In addition to appearing as a standalone Environment slot option, the old skool opening can apply as a prologue wrapper to any other rolled combination. This is a separate probability roll — approximately 5%, independent of all six variant slots — that prepends the old skool phase to whatever environment would have played normally.

The destination is whatever the other slots rolled: the space nebula, the underwater scene, the first-person maze. The prologue starts with rainbow bars and bobs, transitions, and the scene that assembles from the modern rendering is the environment that was always going to play. The viewer does not know which environment they are heading toward until the transition reveals it.

Notable prologue wrapper combinations:

• Prologue → HAM24 nebula — the bobs become stars, the rainbow bars become nebula light shafts, and the HAM24 background fades in as the palette ceiling lifts
• Prologue → underwater scene — flat colours gain depth and the caustic ripple layer emerges as the transition completes, as if the scene was always underwater and the limited palette was merely hiding it
• Prologue → first-person maze — the scroller text runs along the maze wall, and as the transition fires the wall acquires ray-cast perspective depth
• Prologue → Tron grid — the rainbow bars were always the grid lines; the grid was always there behind them, waiting for the perspective transform to engage

When the prologue wrapper rolls, IntroParams carries an additional flag and a prologue duration in frames. The EE prepends the old skool command list to the normal environment command list and crossfades between them via a blended Copper list.

What This Showcases

The old skool transition demonstrates something that no other variant does: the relationship between the classic techniques and the modern ones is not replacement but extension.

The Copper is the same mechanism. The blitter performs the same additive blend. The palette system is the same indirection table. Everything that made the Amiga demo scene possible is present in FireStorm — not as a compatibility layer or emulation mode, but as the natural behaviour of the hardware. The demo coders of 1989 were pushing their hardware to its limits. The Ant64's limits are just considerably further away.

The transition is the machine explaining its own heritage in the only language that matters: live, on screen, in real time, at boot.

New Visual Effects

Several effects are introduced specifically for the intro system, all built from existing blitter and FireStorm hardware primitives.

Snowfall — White/blue-tinted particles with sinusoidal horizontal drift and constant downward velocity. Existing particle system with a wind-offset modulator per particle.

Fireworks — Bloom particle bursts from high screen origins, trajectories fanning outward with initial velocity plus gravity, each burst a different hue. blit.particlelist with BLT_ADDITIVE|BLT_BLOOM. Spark trails handle fading tails. Multiple simultaneous origins.

Bonfire / Fire Column — Rising bloom particles in orange→yellow→white with upward velocity and random horizontal scatter. Intensity highest at base, fading toward tip. Additive blend. A cluster makes a convincing fire column.

Lanterns Rising — Large-radius, low-falloff bloom particles drifting upward slowly with gentle lateral oscillation. Groups of 8–16 at slightly different rates. Warm orange or red. The bloom radius distinguishes them from ordinary particles — they glow like a light source rather than a point.

Aurora / Northern Lights — Copper-driven horizontal colour band sweeps. New background colour register written every N scanlines, cycling through green→teal→purple with a phase offset that is a function of both scanline and frame number. The bands ripple for free. Zero blitter cost.

Falling Petals — Small textured quads (16×16, 4bpp) tumbling with rotation and downward drift, slight horizontal oscillation. Affine sprite blit handles the per-frame rotation. Three petal variants stored: ~384 bytes total.

Confetti Burst — Rectangular quads in saturated colours fanning outward from the impact point, tumbling with affine rotation as they fall. Same mechanism as petals, more chaotic.

Candle Glow — A short vertical bloom line with a teardrop bloom particle at the tip. Intensity oscillates at ~8Hz with slight random phase per candle — the flicker. Multiple instances form menorah, advent candles, Diwali lamps.

Crescent Moon — Two overlapping bloom circles: one at full intensity, one behind and offset at reduced intensity. The overlap region defines the crescent shape.

Aurora Intensification — On specific cue points (logo lock, accent trigger) the Copper's colour sweep rate and amplitude briefly increase then decay back. A reactive lighting event using an already-running effect.

Glitch / Corruption — Deliberate Copper scanline disruption: random horizontal offset writes per scanline, brief palette corruption, occasional brightness flicker. Authentically wrong register writes rather than a simulated effect.

Particle Suspension — Zero velocity assigned to all particles for a configurable hold duration, then full release simultaneously. Used for the Halloween suspended-smash variant. The hold is a physics parameter, not a special effect.

Copper Rainbow Bars — The Copper writes a new background colour register on every scanline, cycling through a sine-modulated hue. A classic Amiga/Atari technique reproduced by the same hardware mechanism on the Ant64. The gradient has 24-bit precision on the Ant64 versus the Amiga's 12-bit; the Copper list structure is otherwise identical to what a 68000 demo coder would have written in 1989. Phase advances per frame to create flowing movement. Speed and direction randomise per boot.

Bobs — Overlapping coloured circles blitted at Lissajous path positions with additive blend. A direct continuation of the Amiga bob effect — the blitter's BLT_ADDITIVE flag is the same operation the original hardware performed. Palette limited to 16 entries in old skool mode. In the transition to modern mode, the flat circles gain a specular highlight map and become physically lit spheres with no visible seam in the changeover.

Sine Wave Scroller — Large bitmap-font text scrolled horizontally with per-character vertical sine displacement driven by the Copper's per-scanline H_scroll register. Identical to the classic Amiga demo scroller technique. Text drawn from a small pool of period-appropriate and anachronistic messages. Font stored at approximately 512 bytes. Sine table at a few hundred bytes.

Procedural Sphere Upgrade — The transition effect that converts bobs into spheres. Over approximately 15 frames, the blitter switches from flat filled-circle rendering to specular-lit sphere rendering at the same screen positions. The transition is linear — each frame the specular contribution increases as the flat fill contribution decreases. The result reads as the hardware becoming more capable of what it was already doing.

Volumetric Bar Upgrade — The transition effect that converts copper rainbow bars into volumetric light shafts. The Copper begins writing to the bloom intensity register alongside the colour register on each scanline. HDR values grow progressively above the old palette ceiling. Over 20–30 frames the flat horizontal colour bands develop glow, depth, and atmospheric character while remaining exactly where they were.

Calendar-Triggered Themes

DeMon reads the RTC at every boot. If the current date matches a themed entry, the rolled variant slots are partially or fully overridden. At minimum the Environment and Audio skin are constrained — enough to make the theme immediately recognisable. At least two slots always remain free to roll from the normal tables so the intro retains technical diversity even on themed dates.

Lunar and lunisolar dates require DeMon to resolve them against a Gregorian equivalent. A compact calendar lookup table stored in flash covers 20 years of lunar/Hijri/Hebrew date mappings at approximately 10KB total.

The rarity system still applies within themes. Themed dates specify which options are available in each slot — not which specific option fires. A Christmas boot might roll the CRT simulation ball on a day that happens to be Christmas. The snowfall is there. The themed audio is there. The technical diversity remains.

Gregorian Fixed Dates

December 25 — Christmas Day

Environment rolls between: snow falling over black void / snow over deep blue / snow over the space nebula as foreground layer.

Protagonist: Boing Ball in red and white checker. Rare (15%): a bauble — a sphere with specular cap highlight and thin vertical stem.

Every smash variant additionally spawns a confetti burst layer. Particles leave a ring of orbiting snowflakes as the logo locks.

Audio: The Ant64 jingle arranged as a sleigh-bell phrase. Short-attack FM operators for the bell timbre — fast attack, fast exponential decay, classic bell synthesis. Choir pad layer using 8 additional VA voices (rare, 30%). Hall FDN reverb always active.

Sub-variants roll freely: snowfall density, whether a candle glow appears in a corner, whether the choir layer triggers.

December 31 — New Year's Eve / Hogmanay

A large countdown numeral appears via the text rendering system as the scene opens, beginning at 10 and decrementing. The ball enters at the moment it reaches zero.

Smash is always fireworks — 4–6 simultaneous burst origins. A second fireworks burst fires symmetrically from both sides of the screen as the logo locks.

Audio: the jingle as a triumphant ascending fanfare. Brass-voiced VA, major key. A procedurally synthesised crowd noise SFX (broadband noise, slow envelope, formant peaks) plays under the fireworks. A large percussion hit from the SFX engine fires at zero.

Hogmanay sub-variant (30%): torchlight aesthetic — orange bloom background tint, fire columns at screen edges, warmer overall colour palette.

December 21 — Winter Solstice / Yule

Environment is always the aurora. Northern Lights Copper band effect over a starfield base layer, deep blue-green-purple sweeping horizontally.

The ball's bloom radius is doubled, casting light onto the aurora beneath it. Slow motion smash always. The orbit reformation always. The aurora intensifies briefly as the logo locks.

Audio: long-attack VA pad, very slow decay, cold harmonics. FDN hall at maximum size. The jingle appears only at logo lock — a single bell tone, nothing before.

November 5 — Bonfire Night / Guy Fawkes

Fire columns at the base of the screen — 3–5 bloom particle fire clusters rising from the bottom edge throughout the sequence.

The ball enters from high in the frame on a falling arc, as if launched. The smash is always fireworks — 8–12 simultaneous burst origins, more than any other date. Fire columns continue throughout. A final single large burst fires directly above the locked logo.

Audio: march rhythm, brass-led VA voices. The SFX engine fires individual firework whistles (rising frequency sweep), bangs (explosion archetype), and a continuous low-level fire crackle. Crowd noise SFX underneath.

Rare sub-variant (10%): one firework is a dud — it launches, then falls without bursting.

November 1–2 — Día de los Muertos

Marigold-orange lanterns rising slowly over a deep black starfield. The ball's checker is replaced with a skull tile texture (16×16, ~128 bytes stored).

The smash is a dissolution — the ball's bloom radius expands dramatically over 10 frames as intensity decreases, the ball fading into a cloud of marigold-coloured particles rather than shattering.

Particles drift upward briefly before being pulled back into the logo — as if they nearly escape.

Audio: minor key FM bell arrangement, slower and more reverent. Karplus-Strong physical model string voice underneath. Hall reverb with extended pre-delay.

October 31 — Halloween / Samhain

Environment rolls between: deep void with procedural moon (large bloom circle, high radius, low falloff) / candlelit scene (multiple candle glow clusters) / CRT phosphor room with green tint rather than white.

Rare protagonist (12%): a pumpkin — procedural ellipse with triangular eye and mouth cutouts via blitter shape operations. Candle glow effect placed inside it.

The smash uses particle suspension: particles hang motionless for 8 frames then release simultaneously. The ghost reformation (particles reveal pre-existing logo) is weighted at 30% on this date vs its normal 3%.

Audio: minor key, slow. SID variant heavily weighted (40%). Damaged/detuned variant also more common (15%). A specific SFX archetype fires on the smash: silence followed by a drawn-out reverberant bang.

October (second Tuesday) — Ada Lovelace Day

Environment is always the Tron grid floor, with a rotating short text excerpt in the font layer.

The protagonist is always a Difference Engine gear — a procedural polygon with radial teeth, rendered as wireframe bloom lines. It rotates.

The gear shatters into polygon shards (small filled triangles with outward velocity) rather than round particles. The logo assembles via the scanline retro rasterisation variant — the most computational-feeling reformation.

Audio: music box arrangement. High-frequency metallic FM timbres, short decay. Mechanical clicking SFX on the gear rotation beat.

September 13 — Programmer's Day (256th day of year)

The C64 composite PAL CRT profile is always active. Background is authentic C64 blue. Colour bleed simulation engaged.

The protagonist is replaced by a blinking block cursor — text rendering system, white, 1Hz blink rate. The ball arrives after two blinks and smashes it.

The cursor shatters into character cell fragments — small rectangles each containing a random ASCII character rendered via glyph blit. The logo assembles from these sorting into position.

Audio is always the SID chiptune variant. Three-channel SID-accurate arrangement: square bass, pulse lead, noise percussion. No exceptions.

June 23 — Alan Turing's Birthday

A dim procedural apple shape rendered in bloom lines appears in one corner — two circles plus a leaf, almost subliminal.

The protagonist is a tape reel — a circle with spokes, rotating. A thin bloom line trails behind it as it bounces, playing out tape.

Audio: always the orchestral VA swell with full hall reverb.

Rare (20%): the apple is half-eaten. Rare (15%): a brief binary grid (0s and 1s in the text layer) appears in the background.

May 4 — Star Wars Day

Environment is always space — starfield or HAM24 nebula.

The ball's checker is replaced with a Death Star surface texture — panel geometry, a bloom particle dish fixed to the sphere surface tracking toward the camera as the ball rotates.

A thin bloom line laser arrives from off-screen just before impact, striking the ball and triggering the smash at the hit point rather than the wall. The orbit reformation is always used.

Audio: brass fanfare arrangement, wide interval jumps, dotted rhythm, full FDN hall. VA brass voices, fast attack. The jingle suggests without copying.

April 1 — April Fools

Starts normally, whichever environment rolled. After one second the glitch effect begins: random Copper scanline offsets, occasional palette corruption, brief flickers.

The ball bounces correctly for two bounces then takes an impossible angle on the third. Corrects itself.

The smash appears to happen, particles begin assembling — then the screen freezes on a single frame for approximately 30 frames. Then releases and completes.

The logo assembles incorrectly first — misaligned, flickering — then corrects. A brief SIGNAL INTEGRITY FAULT text layer message appears and clears (rare, 40%).

Audio: starts in the wrong key, plays two bars, modulates to the correct key. The detuned variant is heavily weighted (60%). Bitcrusher engages briefly mid-sequence.

March 14 — Pi Day

π digits scroll continuously across the background in the text layer — small font, dense, slightly transparent.

The protagonist is always a perfect circle rendered as a bloom line ring, bouncing as a wheel.

The circle shatters into curved arc segments — short bloom line arcs, fragments of the circumference. These organise into a circle briefly before condensing into the Ant64 logo.

Audio: the jingle played at exactly 314 BPM for one bar, then again at 31.4 BPM.

March 17 — St. Patrick's Day

Aperture Grille CRT simulation profile active. Background deep green tinted. Ball checker in green and gold.

Audio: jig rhythm, 6/8 feel, VA fiddle-like FM timbre.

Rare: a small shamrock (three-petal bloom line shape) briefly appears and is then smashed by the ball.

February 29 — Leap Day (every 4 years)

Environment always space. Protagonist always two balls — the collision variant is forced. Reformation always the orbit-then-spiral variant. Audio always the full orchestral VA swell.

Rare (20%): a small calendar "29" numeral appears in the text layer and is smashed by the collision.

February 14 — Valentine's Day

Background has slowly drifting heart shapes — each heart is two small bloom circles offset diagonally, various sizes, deep red tones.

The ball's checker is red and pink. Each bounce impact produces a small heart particle cluster at the contact point.

Every particle in the smash is rendered as a paired bloom circle — a heart shape. The orbit reformation is used, with orbital paths following a cardioid curve rather than a standard circle.

Audio: slow, expressive, rubato style. VA strings, BBD chorus at maximum depth, hall reverb. Piano-like attack on the melody.

The logo, once assembled, pulses with the heartbeat effect — brightness modulation at 72 BPM for three beats (rare, 25%).

January 25 — Burns Night

Deep void with a small thistle rendered in bloom lines — 8 radiating petals from a centre point, thin vertical stem, placed dimly in a corner.

Ball checker in Saltire blue and white.

Audio: bagpipe-adjacent VA timbre — FM patch with a continuous fixed-pitch drone note underneath the melody, double-reed formant character.

Lunar and Lunisolar Dates

These dates are resolved against Gregorian via the 20-year calendar lookup table stored in flash.

Chinese New Year (1st day, 1st lunar month)

Red lanterns rising — 12–20 warm amber/red lantern bloom particles drifting upward over a starfield or deep red background.

The protagonist is replaced by the current year's zodiac animal, rendered in bloom lines from a stored compact vector path. Each of the 12 animals is encoded as 16–32 line segments (~200 bytes per animal, ~2.4KB total for all twelve). The shape bounces and orbits. This is the only effect in the system that changes on a 12-year cycle.

Smash is always combined fireworks burst and confetti explosion. Red and gold only.

Audio: pentatonic scale, erhu-like two-operator FM timbre. Gong strike at smash moment — FM bell, very low pitch, fast attack, long decay.

Rare (25%): the zodiac animal lingers briefly as a ghost image as the logo forms over it.

Diwali (Amavasya of Kartika month)

20–40 diya candle glows arranged in a rangoli-inspired symmetric pattern over a deep black background. Each diya is a small flame bloom particle, warm orange, flickering at a slightly randomised rate.

The ball's bloom radius is set to maximum — warm gold — and it noticeably brightens nearby candles as it passes (proximity effect via the layer blend register).

Smash launches fireworks in gold, orange, and deep red only. Candles continue throughout. At logo lock all candles simultaneously flare to maximum intensity, then return to their gentle flicker.

Audio: sitar-like FM timbre with pitch envelope drop after strike. Tabla SFX percussion. Jingle in a Bhairavi raga-adjacent mode.

Eid al-Fitr (1 Shawwal, Islamic Hijri calendar)

Starfield always. A crescent moon — two overlapping bloom circles, one offset and dimmer, creating the crescent shape — positioned upper right throughout.

Ball checker in green and white. Rising star particles in the smash — five short bloom lines meeting at a centre, ascending with the normal particle cloud.

Audio: Maqam Rast modal arrangement (natural third, slight neutral quality). VA oud-like timbre — plucked, short decay, warm mid-frequency. Long FDN reverb.

Rosh Hashanah (1 Tishrei, Hebrew calendar)

Warm honey-gold Copper-driven background. Apple shapes in bloom lines.

Audio: klezmer-adjacent arrangement — minor key, portamento slides between notes (VA engine per-note portamento), clarinet-like FM timbre. Optional shofar-like opening sound (descending then rising FM glide) before the jingle.

Hanukkah — first night (25 Kislev, Hebrew calendar)

A menorah in bloom lines — 9 vertical candle glows, the shamash centred and raised. On the first night: shamash and one candle lit. The candle count accumulates across nights if DeMon detects consecutive daily boots via the boot counter and RTC.

Ball checker in blue and silver. Candle glows disturbed briefly by the smash shockwave. Logo assembles while the menorah continues in the lower frame.

Audio: klezmer character, faster and more festive than Rosh Hashanah. A dreidel spin SFX before the ball arrives — high-frequency FM whirr with downward sweep as the imagined spin slows.

Holi (day after Purnima in Phalguna, Hindu calendar)

White/pale background — the only intro variant with a light backdrop. The Copper drives a clean white gradient.

The ball's checker colours cycle with every bounce — each bounce a new saturated hue pair via Copper palette writes between contacts.

The smash produces a full-spectrum confetti burst — every particle a different saturated hue, the most visually rich explosion in the system.

Particles sort by colour group as they reform — matching hues pulling toward the same logo vertices. The logo assembles from colour-coded zones.

Audio: festive, fast, percussive. Tabla-like rapid SFX pattern driving under the FM melody.

Rare: the background progressively accumulates colour from particle impacts via an additive blend layer — becoming increasingly stained as the sequence progresses.

Vesak / Buddha Day (full moon, 4th or 5th lunar month)

White and pale yellow lanterns rising. Half-speed protagonist movement throughout. The dissolution smash — ball fades to a luminous cloud rather than shattering. Particles rise before descending into the logo.

Audio: always the granular ambient variant. Long grain cloud. The logo lock is accompanied by a single singing bowl tone — FM bell, very long decay, pure sine.

Rare: a lotus flower in bloom lines (8 short curved petal lines) appears briefly as the logo assembles.

Obon — first night (August 13, or lunar equivalent)

Twilight Copper palette gradient: deep blue top to orange-black bottom. Paper lanterns rising — 8–12 warm amber, slowly ascending.

The ball is rendered at reduced layer opacity (~70%) so lanterns are faintly visible through it. The dissolution smash. Particles drift up before being recalled.

Audio: shakuhachi-like VA timbre — breathy FM, flutter-vibrato LFO. Slow, pentatonic, melancholic. Long FDN reverb. Optional taiko drum SFX at the opening.

Secular and Technical Calendar

November 30 — St. Andrew's Day

A Saltire — two long bloom lines on the diagonal — fills the frame behind the ball action.

Ball checker in Saltire white and dark blue. Bagpipe FM timbre as Burns Night, faster and more martial arrangement.

July 4 — American Independence Day / July 14 — Bastille Day

Night sky, starfield. Fireworks smash always. The burst pattern traces a rough star shape before dispersing for July 4th. Particle colours are red/white/blue progression for July 4, blue/white/red for Bastille Day.

Bastille Day sub-variant: accordion-like VA timbre layered under the jingle — lightweight two-operator FM with rapid vibrato and a nasal formant peak.

Themed Randomness Philosophy

Calendar themes constrain, they do not dictate. The rule applied to every themed date is: at minimum, lock the Environment and Audio skin to themed options. Leave at least two slots to roll freely from the normal tables.

This means a Christmas boot might produce the SDF morph reformation or the slow motion smash. The snowfall is there. The sleigh-bell jingle is there. The technical diversity of the system is still on display.

The experience should always feel like the Ant64 intro on a special day — not like a separate product that only appears on holidays.

Easter Eggs and Milestone Triggers

DeMon maintains a boot counter in FRAM, incremented on every power-on. The EE receives the current count in IntroParams.

Boot 1000 — On the thousandth boot, the logo assembles with a small :1000: subtitle rendered in the text layer. It holds for approximately two seconds then fades before the OS handoff.

Specific jog dial combination at power-on — A hardcoded combination of the 8 dial positions maps to the "damaged/detuned" forced combination. Like a dirty cartridge. The combination is the code.

Single jog dial held at power-on — Forces the maze variant. Independent of the normal skip mechanism.

Two specific jog dials held at power-on — Dual Tate mode intro: two corridors side by side at 4K output, two balls, two simultaneous sequences. Uses the 270×480 Tate mode native resolution, two independent layers side by side.

Hardcoded RNG seeds — Certain seed values are mapped to specific legendary combinations regardless of what the normal roll would have produced. These seeds can be shared as documentation easter eggs, at events, or embedded in the website. A seed is six bytes — one per variant slot — and produces the same boot on any machine that generates that seed.

The Rarity Ledger

DeMon logs each boot to a small DBFS table after the OS is running. The combination identifier is compact: one byte per slot × 6 slots = 6 bytes per entry plus a timestamp. 1000 boot records occupy approximately 14KB.

An AntOS script — boot.history — queries this table and displays the owner's personal collection: which combinations they have seen, how many times, and when they first appeared. The Christmas boot is guaranteed annually. The Leap Day boot appears four times per decade. The Chinese New Year zodiac animal cycles over 12 years.

Someone who has owned their Ant64 for 12 years has seen every zodiac animal. That is a feature, not a side effect.

Storage Summary

Base assets (no rotoscope / MOD):

EE bytecode — all variant modules and themes:    ~128 KB
Copper command lists (all variants):              ~20 KB
HAM24 nebula backgrounds (×2):                  ~304 KB
HAM24 underwater backgrounds (×2):              ~304 KB
Maze cell map + wall textures:                    ~34 KB
Ant64 logo SDF path data:                          ~4 KB
Fuji logo SDF geometry:                            ~2 KB
12 zodiac animal vector paths:                   ~2.4 KB
Petal / leaf quad textures:                       ~0.8 KB
Demo scene font (16×16 bitmap, full ASCII):       ~0.5 KB
Sine displacement table (scroller):               ~0.3 KB
Lissajous path tables (bobs):                     ~0.5 KB
Prologue scroller text pool:                      ~0.2 KB
Audio note/step sequences — all variants:           ~4 KB
Calendar lookup tables (20 years):                ~12 KB
Themed Copper lists and effect constants:          ~8 KB
Fireworks star trajectory tables:                ~0.5 KB
Variant RNG weights table:                         ~2 KB
Miscellaneous LUTs:                               ~2 KB
──────────────────────────────────────────────────────
BASE TOTAL:                                      ~829 KB
BASE RESERVE (in 4MB):                          ~3.37 MB

With rotoscope animation and MOD library:

MOD pattern + order data (4–6 tracks):            ~24 KB
  (sample/instrument data lives in audio partition)
Rotoscope sequences (×7, vector geometry,
  mixed keyframe rates, with span cache):          ~373 KB
MOD augmentation tables + frame indexes:             ~5 KB
──────────────────────────────────────────────────────
ROTOSCOPE + MOD ADDITION:                               ~402 KB

GRAND TOTAL (base + rotoscope + MOD):                 ~1,231 KB
REMAINING IN 4MB PARTITION:                           ~2,963 KB

Storing figure animation as interpolatable vector geometry rather than compressed pixel deltas reduces per-sequence cost from ~640KB to ~74KB. Instrument and sample data for the MOD tracks and synthesis augmentation live in the audio system's own flash partition — the intro partition stores only pattern data, note sequences, and augmentation mapping tables. Fill effects (starfield, nebula, particles, fire, aurora) are rendered at runtime by the FireStorm compositor and contribute no storage cost. Combined, these factors reduce the rotoscope and MOD addition from a potential ~3,825KB pixel-based estimate to approximately 397KB.

The 4MB flash partition is approximately 20% utilised. The reserve accommodates future variant additions, higher-resolution HAM24 backgrounds, additional zodiac or themed vector art, and any effects that require stored geometry. The system has substantial headroom for the Ant64's entire production lifetime.

The standalone demo works live in a separate flash partition and are not included in the above figures. See Ant64 Original Demo Works for their storage breakdown (~1,040 KB in a dedicated partition).

Demo Works

The Ant64 ships with a set of standalone original demo pieces — complete works ranging from 60 to 180 seconds, designed to be experienced as authored statements rather than boot-time showcases. They are documented separately:

Ant64 Original Demo Works · Ant64 Open Source Games

The demo works include:

• State of the Art — Extended — a direct creative sequel to the Spaceballs Amiga demo from 1992, using three original figures, original music, and the full capability of the Ant64 hardware simultaneously. The centrepiece of the collection.
• Silhouette — a single figure whose silhouette evolves from a flat 1983-style shape into a stencil for the HAM24 nebula, particle systems, and aurora effects, ending with the figure's vector outline morphing into the Ant64 logo.
• Copper — a 120-second piece that opens as a technically exact 1990 Amiga demo and evolves through the same hardware mechanism throughout, the Copper writing progressively more ambitious register targets.
• Weight — an original work with no retro lineage. A figure lit in real time by frequency analysis from the audio DSP, in bidirectional feedback with the granular engine.
• Heritage — a tribute to Gary Gilbertson's "Passionately" (1983), contingent on the composer's permission.

All works will be released as public domain (CC0) with full source material upon the Ant64's commercial release.

Hardware References

The intro system is grounded in documented Ant64 hardware capabilities:

• FireStorm FPGA — EE, blitter, DSP pipeline, Copper, layer compositor
• Display System — HAM24, CRT simulation, DDA ray cast units, Mode 7, native resolution system
• Blitter — particle lists, bloom lines, SDF rendering, affine transforms, texture system
• Audio System — VA, FM, 303, granular engines; BBD chorus; FDN reverb; environmental DSP presets
• DeMon — supervisor RP2350, RTC, FRAM, QSPI to FireStorm, SG2000 reset control
• Pulse — audio/MIDI RP2350; establishes QSPI connection to FireStorm after its own boot; not a dependency for the intro
• Mod Archive — source library for ProTracker MOD tracks used in the State of the Art variant
• Demozoo — Passionately — original 1984 release documentation for Gary Gilbertson's composition
• Gary Gilbertson interview — background on the composer and history of "Passionately"