VWE TESLA · Division VelociRender · i860 firmware emulator

The board's own firmware
is rendering again

A cycle-faithful Intel i860 interpreter now runs the game's actual shipped firmware — booted, initialised, and fed a complete recorded mission over the wire. It replays every command, emits the real PXPL5 IGC render stream, and projects the scene geometry. Below is an object it drew, its vertices and normals pulled straight off the emulated chip and reconstructed in 3D — geometry this board's firmware has not computed in thirty years.

reconstructed · firmware geometry + normals
the object cap7 was drawing — its 45 projected vertices resolve into a complete 9×5 height-field surface, rebuilt here in true 3D and lit by the board's own per-vertex normals. Pulled live off the emulated i860.
trace · i860 execution → IGC command DMA
26,422
wire commands replayed (whole mission)
8,562
draw_scene frames processed
191/192
screen regions binned with geometry
0
unimplemented ops remaining on the path

01 The render signal chain

Nothing here is re-interpreted by us. Each stage is the firmware's own code executing on the emulated i860 — from parsing the wire packet to writing the bit-serial micro-program the Pixel-Planes array runs.

in
Wire
dN_receive → 42-action dispatch
cpu
i860
transform · clip · classify
geom
Binitize
per-region 64×128 bins
out
IGC DMA
SEND / TILE / FLUSH stream
px
Pixel-Planes
array model simulated · §05

02 The output, decoded

The firmware DMAs the render to the card as an opcode stream (DMAENGN.H). Both panels below are captured verbatim from the emulator. Left: a real per-region command list — every region references the same tile-relative payloads and differs only in its TILE id and the GOTO link. Right: inside a SEND — the payload isn't opaque, it interleaves control words with the actual float coefficients, swept bit-plane by bit-plane into pixel memory.

 region 0x0801fa40 · DMA list
# addr            opcode
0x08015000  SEND(4)      ; edge coeffs
0x00000000  FLUSH
0x08015020  SENDE(0x45)  ; z / colour
0x00000000  FLUSH
0x08014100  TXDN
0x08015260  SEND(0x21)
0x08015380  SEND(0x29)
0x00000020  TILE     ; tile id
0x0801f008  GOTO     ; → next region
 SENDE target 0x08015020 · payload
# bit-serial sweep (MEMpluseqMEM)
+000  00000100   ; header
+004  3a804834   ; = 9.79e-4  float
+008  8401213a
+00c  00000021   ; bit-plane 0x21
+010  ba01253a   ; = −4.93e-4  += A
+018  8381213a
+01c  00000022   ; bit-plane 0x22 …

Pull the floats out of those payloads and they line up into clean ×2 chains0.0079 · 0.016 · 0.032 · 0.063 · 0.126 · 0.252 · 0.504 · 1.009 — a coefficient stored as its binary place values C·2ᵏ, one per bit-plane, exactly how a bit-serial adder holds a number. And the recovered values are the object's own geometry: a payload edge coefficient (0.12527) lands on the edge normal computed from the captured vertices (0.12555) to 0.2%. The plane constants sit alongside as fixed-point screen coordinates (0x0000ec00 = 236.0, a vertex x). The coefficients feeding the array simulator (§05) are the ones the hardware actually shipped.

03 Where the geometry landed

At the frame flush the firmware walks the screen-bin array and hands the IGC one descriptor per 64×128 region. This grid is drawn from the real captured descriptor scan — filled cells are regions that received transformed geometry. A full mission view fills nearly the whole frame: ground plane and sky, exactly as expected.

region has geometry empty region (shared page) 96 × 2 descriptor grid · 191 of 192 filled

04 How the death-camera saw it

The surface above is the same 45 vertices, sorted back into model space — they form an exact 9 × 5 height-field grid (x and z in even 2-unit steps, y the height at every node; all 45 cells filled). What the board actually wrote to screen is below: cap7's death-camera views that surface nearly edge-on, so the frame the i860 projected is a thin, folded sliver. It is authentic output — just an awkward angle. Left, that projection Gouraud-shaded; right, its raw VSTRIP wireframe.

the board's screen-space frame — Gouraud-shaded, grazing near-edge-on angle
raw VSTRIP wireframe — 4 strips, 45 vertices, exactly as the i860 emitted them

05 The Pixel-Planes array, simulated

This is the final stage in silicon — and it now runs in software. The PXPL5 IGC is a region rasteriser: the screen splits into 64 × 128 tiles; every pixel carries a 26-byte bit-memory and an enable bit; all pixels evaluate one linear tree in lockstep — eval_ltree(x,y,A,B,C) = (int)(x·A + y·B + C). A triangle becomes three edge trees into the enable register, then Z and R/G/B planes interpolated per pixel and z-buffered in pixel memory (IGCOPS.C). Fed the captured surface, the model lights the tiles below and renders pixels that match our reference rasteriser to within edge anti-aliasing — the array reproduced faithfully.

the depth buffer, read straight out of pixel memory — the 24-bit Z plane the SENDE z-sweep interpolates (near = bright)
the object's footprint — 18 of 50 64×128 tiles lit, each a region of pixel processors
pixel memory · 26 bytes = 208 bits
Z · 24bR·8G·8 B·8enable + working bits
  • three edge trees → the enable register (the inside test)
  • Z / R / G / B are planes, evaluated per pixel by the linear tree
  • z-buffer via MEM2geMEM2; every write gated by enable
  • the depth image (left) is that Z plane, read back out of pixel memory
  • validated pixel-faithful to the reference — ~1%, at edges only

What this is not, yet: a full from-scratch run of the compiled micro-code the DMA ships (§02) — the form the geometry takes on the wire to the card. But that stream is now largely decoded: the command lists read cleanly, the SENDE z-sweep resolves into a regular 4-word instruction, and its coefficients are the same ones driving this depth buffer — the array's inputs are cross-validated against the hardware's own compiled stream. And scanning all 14,223 payload writes of this draw, every screen coordinate lands in the object's own range (x 66–236) — this death-cam frame carries no geometry beyond the object; the rest is a background clear. So the array's render above isn't one primitive of many: for this frame, it is the geometry.

06 The warp field — a Star Trek scene, recovered

The archive's trek capture — unreleased Star Trek material — replays and draws after the dual-instruction-mode fix. Walking the per-region DMA chains in the bin pages enumerated 898 compiled payload programs for the frame: four are the standard end-of-frame pipeline (fog, texture, RGB — byte-identical in every capture), and ~860 are the scene itself, per-primitive coefficient blocks with their geometry sitting in plain screen-space floats. Plotted below: 433 star positions and 389 streaks, radiating from a convergence point — the warp-speed starfield, reconstructed from micro-code compiled by the board's own firmware running on the emulated i860.

recovered from the frame's compiled payload programs
trek at warp — every point and streak is one primitive's position read from its compiled coefficient block (fields +0x14/+0x18 and +0x24/+0x28, plain IEEE floats in screen space).
same recovery · the Klingon capture
the Klingon scene — 96 positions and 62 edge segments: a sparse starfield with a dense tangle of intersecting edges right-of-center — a vessel, recovered by the identical chain-walk from the klngvid capture.

07 What it took to get here

The i860 core was corrected against the toolchain's own assembler output and MAME's validated i860 model. A selection of the load-bearing fixes:

store encoding
i860 stores keep the source in bits 15:11 and split the offset — every function return went to 0 until this was found. Prologues now save r1.
op 0x13 escape
lock / calli / unlock share one opcode; everything decoded as calli, so every spinlock jumped to address 0. The phantom "exit stub."
FP pipeline
Exact PFAM/PFMAM dual-ops, per-stage precision, fdest bypass. The Newton–Raphson divide now yields 16 ÷ 16 = 1 through the pipes, unhooked.
pipelined pftrunc
Float→int through the adder pipe — a form no prior i860 emulator implemented. Killed an 8.3-million phantom-row loop.
IGC drain
Per-page completion is nonzero-on-done, and consumed pages reset their write index. Frames stopped saturating after ~1,400 draws.
Landed Firmware → render command stream, end to end

Verified working

  • Cold boot of the capture's own firmware build on the emulated i860
  • Full recorded mission replays to completion — 26,422 commands
  • Scene graph, transform, frustum classify on real geometry
  • Real PXPL5 IGC opcode stream emitted and decoded (SEND / TILE / FLUSH)
  • Geometry binned into 191 screen regions
  • Object recovered and shaded — a 9×5 height-field surface, lit by the firmware's own normals (above)
  • Pixel-Planes array simulated (§05) — 64×128 tiles, per-pixel memory, edge trees + z-buffer, validated pixel-faithful

The last mile to pixels

  • The array's computational model runs and matches the reference — the piece left is executing the board's own compiled micro-code
  • The per-region DMA command lists decode cleanly (§02) — SEND / SENDE / TXDN / TILE / GOTO, tile-relative
  • The SEND payloads carry real float coefficients in a regular bit-serial sweep — recoverable, not opaque
  • Coefficients verified to 0.2% against the geometry; for this frame, the object is the geometry (§05)
  • cap7 redraws this one object every frame — confirmed identical at cmd 735 and cmd 19,889, same 9 coordinates. A battle scene with terrain is a different capture entirely