Zhaozhou

01 — THE MACHINEWhat Zhaozhou is

Zhaozhou is a console architecture designed for the SuperStation One — a MiSTer-family board built on a Cyclone V FPGA. It is not a miniature PC GPU. The charter puts it plainly: it is “a purpose-built machine for transforming small authored inputs into overwhelming geometric motion.”

The defining idea is an inversion of how detail normally works. On a conventional machine, a model carries its own level of detail: an object is “high poly” or “low poly” as a property of the asset. On Zhaozhou, detail is a budget allocated by projected pixel importance — how much screen a thing actually occupies this frame decides how much geometry it gets. An army of a hundred creatures collapses continuously from full geometry to tiny meaningful moving forms, and nothing about the asset changes.

The second idea is that the ground remembers. Terrain is a live heightfield driven by field programs — small deterministic bytecode programs that deform it — plus a persistent per-patch surface sheet that records scarring. Craters, ridges, trenches and travelling waves are not decals. They are the terrain, and they stay.

What it is for

• Large outdoor battlefields with deformable terrain that permanently records battle damage
• Huge quantities of particles, many represented as actual low-polygon geometry rather than sprites
• Large procedural spells — geometry generated on the fly, not authored
• Two simultaneous local-player cameras and hard 60 Hz presentation

The three frozen display modes

Duo costs almost nothing extra to raster: 98,304 3D pixels against Z60’s 92,160 — 6.7% more. The second camera adds geometry work, but simulation, terrain deformation, creature animation and particle simulation stay shared. Split-screen was designed in from the start rather than bolted on.

The laws that do not bend

• 60 Hz is a contract. A late frame is never partially displayed. The previous complete frame repeats and a deadline fault is recorded.
• The frame rate does not negotiate; form negotiates. LOD, particles, material cost and auxiliary effects degrade coherently before frame timing does.
• No hardware feature exists without an executable reference, counters, captures and differential tests.
• Reserve is a feature. At least 10% fabric and timing headroom is kept until the complete core is stable.

02 — GALLERYWhat the oracle produces

These four images are the reference renderer’s actual output, converted from its RGB565 canvas without regrading, then scaled 3× with nearest-neighbour so 240p reads on a modern display. Each caption says exactly what produced it.

Reminder: reference-oracle renders, not hardware. These came out of zref::render, a deliberately slow, integer-only, CRC-able C++ implementation with no floating point anywhere in the render path. Its job is to be the definition of correct, not to be fast.

In motion — the deformation reel

Deformation is the one thing a still cannot show. These three loops are the reference oracle's actual frame sequences, encoded palette-exactly: each subject's frames share a single ≤256-colour palette of their own, the GIF is encoded against that palette with dithering off, and the encode is verified by decoding the GIF back and comparing every frame byte-for-byte against the captured canvases. What the loop shows is what the oracle rendered — no re-quantisation, no dithering, no interpolation.

Development-state renders. These run on today's single-heightfield terrain renderer. The dual-heightfield island format — true thickness, undercuts, holes punched clean through — is specified and frozen, and the renderer move is the next terrain wave. These loops will be regenerated and promoted when that lands; what you see here is where the machine is now.

Native-resolution copies of all still images are published alongside the scaled ones under renders/native/, in case you want the untouched pixels. Each animated subject also keeps a representative still beside its loop.

03 — STATUSWhere the project actually is

Every number below was read out of the repository. Nothing here is rounded up, and the zeroes are as load-bearing as the rest.

The maturity ladder

Every block advances one rung at a time, and each advance must be justified by pinned evidence that a validator checks against git history. The ladder has seven rungs. The project stands on rung four, for six blocks out of eighty-seven.

Of the 87 blocks, 72 are FPGA/RTL blocks and 15 are software. The six at RTL_VERIFIED are the memory and I/O spine — the VRAM arbiter, the HPS bridge, the memory guard, the input snapshot and rumble paths, and the audio FIFO — verified in simulation against their C++ references, with formal properties where the property is expressible.

Six further blocks carry blocked_on: hardware (SYS.PLL, SYS.RESET, SYS.CDC, MEM.SDRAM, SW.TOOLS.REPORT, SW.TOOLS.BOARDPROBE). The ledger validator refuses to advance them past SPECIFIED no matter what evidence is offered, until the hardware lane opens. That is a mechanically enforced honesty rule, not a convention.

Tests

One of the 48 fast tests, the clang-format gate, skips cleanly on this machine because clang-format is not installed. ctest counts that as a pass; this page counts it as a skip and says so.

Formal proofs

Five properties are registered for bounded model checking. Two are now genuinely established, and the distinction is one this project learned the hard way.

Because that liveness property does not currently hold, MEM.VRAM.ARBITER sits at RTL_VERIFIED while citing a proof that fails. The ratification record says the block drops a rung to UNIT_VERIFIED if the corrected bound cannot be proven. That is an open item, and it is listed here rather than waited out.

What the reviews caught

Adversarial review is the part of this project worth writing down. A consolidated review found three critical and five major defects, and an earlier one found a sixth of the same character. Every one of them was found while the entire test suite was green.

• A SPLINE opcode that violated its frozen specification by a factor of 2¹⁶ — and did so identically in both the C++ and the TypeScript interpreter, so the differential test that compared them agreed perfectly.
• A sun that was invisible. Its centre alpha was computed as (a+128)>>8 on a value clamped to 0x10000, so full brightness wrapped 256 → 0. Any sun energy above about one third rendered nothing at all.
• A sky whose 48 drum columns collapsed to a single angle: a turn fraction was shifted right by 16, so all 1,536 band triangles landed on nine distinct X coordinates, every one of them zero-area. The bands never rendered.
• An fx_sin that read one entry past its 257-entry table, on inputs as ordinary as fx_cos(0).
• A fill rule that dropped shared-edge pixels on both sides of the edge — a strict comparison where the specification pinned a non-strict one, so neither triangle claimed the seam. Measured on a directed case: ten holes before, zero after.
• A formal proof that had never once been elaborated. Its assertions were implications on a signal a driver defect made unreachable, so it passed vacuously. When the lane was made real it failed immediately — and this had happened twice, on the same lane, to two different blocks.
• An arbiter liveness bound that fails when actually proven, described above.

Making the memory-guard proof real also surfaced a genuine escape: the blit_span field was unclamped, so blit_base + blit_span could wrap 32 bits and the wrapped window admitted writes far outside the map. All of the above are fixed and pinned to commits. The reason they are on this page is that a green suite is evidence about the tests, not about the design.

Phases

The charter defines fourteen phases, 0 through 13, each with a hard acceptance gate. One phase has a written gate report. Substantial merged work exists beyond it — memory, input, audio, the Form language frontend, the whole software renderer these images come from — but no gate report covers it, so it is not claimed as gated.

The one outstanding Phase-1 gate is “one tiny Form program parses, type-checks and lowers to deterministic C++”, deliberately deferred to Phase 3 by the build plan. The report that records this says so itself, in writing.

First synthesis

Synthesis has been run exactly once, and not on the console.

Three caveats, all of which matter more than the numbers. The design under synthesis is the ABI probe — a 52-line streaming CRC-32C engine over the generated ABI package — not the console. The part is provisional: the real device ordering code is Phase-0 board truth and is not yet known. And the numbers live in a commit message rather than a parsed report, because the report parser is deliberately untested until it has a real Quartus fitter report to eat. Consequently no block records a measured resource figure, and no block is SYNTHESIZED.

There is no timing closure data and no bandwidth data. Those directories exist and are empty on purpose.

04 — BLOCKEDWhat needs physical hardware

The repository keeps a written list of everything it cannot honestly do without a board, and refuses to guess any of it. This is that list.

• Board truth. SDRAM memtest, real timing constants, sequential and strided bandwidth, burst latency versus length, clock-tree stability, input latency. The file reports/board_truth.json does not exist — by design. No probe result has ever been simulated or assumed, so the SDRAM timing constants remain explicitly cycle-approximate.
• The MiSTer framework. The upstream sys/ directory is not vendored yet, which blocks the PLL, reset and clock-domain-crossing blocks.
• Synthesis and timing closure. Fitter reports, resource figures per block, and any claim that timing closes with margin.
• The top three maturity rungs. SYNTHESIZED, INTEGRATED and HARDWARE_PROVEN are unreachable for all 72 RTL blocks until the hardware lane opens.
• The soak tests. The eight-hour simultaneous video/input/audio/memory stress and the twenty-four-hour memory stress. Not runnable, and explicitly not simulated.

And what simply is not built yet

• The Wound Lab demo does not exist. The charter specifies it in detail — one floating island, two player wizards, two 256×192 cameras, three creature species, twelve units per player, and four spells (Raise, Break, Wave, Shatter). None of it is implemented; the directory holds a placeholder file and nothing else. The marker sigils in the renders above are 8×8 test patterns standing in for wizards, not wizards.
• The RTL rasterizer is not started. All five raster blocks — tile store, edge walker, early-Z, fragment and resolve — are contract-only at SPECIFIED, and the raster RTL directory is empty. The rasterizer that produced every image on this page is the software one, in C++. That is Phase 4 and 5 work.
• No geometry frontend, no creature system, no particle RTL, no compositor. Those are Phases 8 through 11.

05 — METHODHow it is being built

The interesting part of this project is not the renderer. It is the rule that nothing is allowed to exist as hardware until it already exists as something testable.

Every hardware block must have, before any RTL is written: an executable reference implementation, directed tests, randomized differential tests against that reference, and formal properties where a property can be stated. A block advances one rung at a time and each advance is pinned to evidence a validator re-checks against git history. Six blocks are blocked on hardware and no amount of evidence can move them — the tool enforces it.

The command ABI is generated from a single interface definition into C++, TypeScript and SystemVerilog, and the three are held byte-identical by a conformance test that fails on any drift. The field-program interpreter exists twice, in C++ and TypeScript, and a fuzz-parity test compares them on generated corpora. Frame packets are sealed, validated fail-safe, and replayed; canvases are pinned by CRC-32C. There are no floating-point operations anywhere in the render path — the software renderer is integer-only precisely so that hardware can match it exactly rather than approximately.

The lesson the project keeps re-learning, and keeps writing down: a green suite is evidence about the tests, not about the machine. Counting primitives is not the same as checking that a pixel was written.