Zhaozhou

01 · THE MACHINEWhat Zhaozhou is

Zhaozhou is a console architecture aimed at real, fabricated silicon: a physical machine of its own. The working proving ground along the way is an FPGA core for the SuperStation One, a MiSTer-family board built around a Cyclone V FPGA. That core is a step on the road, not the destination. It is not a miniature PC graphics card. The project charter calls it “a purpose-built machine for transforming small authored inputs into overwhelming geometric motion.”

The defining idea inverts how detail normally works. On a conventional machine, a model carries its own level of detail: an asset is “high poly” or “low poly” by nature. On Zhaozhou, detail is a budget, allocated by how much screen a thing actually occupies this frame. An army of a hundred creatures collapses smoothly from full geometry down to tiny meaningful moving forms as it recedes, and nothing about the assets changes.

The second idea is that the ground remembers. Terrain is a live surface deformed by small deterministic programs. Craters, ridges, trenches and travelling waves are not painted-on effects; they are the terrain itself, and they stay.

What it is for

• Large outdoor battlefields whose terrain permanently records damage
• Huge quantities of particles, many as real low-polygon geometry rather than flat sprites
• Large procedural spells: geometry generated on the fly, not authored
• Two-player split-screen at 60 frames per second
• A Steam release of the game, once the machine exists

The three display modes

Split-screen was designed in from the start, not bolted on: Duo draws only 6.7% more 3D pixels than the single-player mode (98,304 against 92,160), and the simulation, terrain deformation and particles are shared between the two views.

The rules that do not bend

• A late frame is never partially shown. The previous complete frame repeats and the miss is recorded.
• When a frame gets expensive, form gives way first. Detail, particles and effects degrade before frame timing does.
• No hardware feature exists without an executable reference and tests that compare the two.
• Reserve is a feature. At least 10% of the chip is kept free until the complete core is stable.

02 · GALLERYWhat the reference renderer produces

These images are the reference renderer's actual output, converted straight from its 16-bit canvas without regrading, then scaled 3× with no smoothing so 240p reads on a modern display. Each caption says exactly what produced it.

In motion: the deformation reel

Deformation is the one thing a still cannot show. These loops are the reference renderer's actual frame sequences, encoded with each subject's own exact colour palette and verified by decoding the file back and comparing every frame byte-for-byte against the source. What the loop shows is what the renderer drew: no re-compression, no dithering, no interpolation.

Development-state renders. Renderer changes re-captured every loop on this page: the sky now projects with true perspective under a colour-continuity law (the old sky read as flat ovals); islands use the dual-heightfield format with a modelled top and bottom surface, so holes can be punched clean through; and island surfaces are now textured per polygon over a deep keel. All pinned checksums were re-derived and re-committed with those changes, deliberately and in writing. The diary section below preserves what the islands looked like before the keel: flat-shaded colour on a 22 m sheet.

Creatures: rings, bones and a ladder down to glints

A creature is a list of ring-cylinders stitched into meshlets and hung on at most 32 bones. Animation is 8 bytes per bone per frame, packed quaternions decoded on demand into a shared pose cache, and nothing ever blends: one clip hard-cuts to the next, exactly as the donor shipped it. The body tilts with the ground under it because two height samples per tick say it should. When the camera retreats, the whole animal collapses through a ladder of representations, ending as a two-pixel glint.

The sky and the stars

The sky is geometry and the stars are palettes. Star colour never exists at draw time: the disc and its corona are drawn as intensity through a 64-entry colour ramp the CPU rebuilds each frame, which is how Noctis IV coloured its entire universe, and it is native territory for a palette console. Lens flares are frozen-table sprite splats into a quarter-resolution glow plane; there is no shader anywhere, because the machine refuses to have any.

Suns, seen from the ground

Ten worlds. On each one the sky and the sun are the same thing: a single brightness field with one colour table laid over it, so a world's whole identity is a handful of numbers rather than a sky asset and a star asset that have to be kept in agreement. The sun is drawn straight into that brightness field and allowed to overflow, which is why it has no edge and no colour of its own. It takes the colour the sky reaches at its brightest.

That is also why these fit. The whole sky, however enormous the sun, can only ever select the colours in one table. The largest sun in this set produces the loop with the fewest colours in it.

A sun seen through thick air

Two loops of the same sun setting over the same island, from the same camera, with one number changed between them. Noctis IV is at its best when it puts a star behind a heavy atmosphere, and this is the console attempting the same thing. The pair is published together so the claim can be checked rather than taken on faith.

The star catalogue

The console carries a twelve-class star gamut taken over from Noctis IV with its exact colour tables, and the library now screens every live class. The six loops below are generated straight from the effects-library catalogue in the repository: the same file pins each loop's checksum, so a listing here is a claim the repository can re-derive. The other three live classes appear above (the yellow flare sweep, the boiling red giant, the pulsar); the three dead classes have no flare and no screen by spec law. Every moving sun drags a smear behind it now: eight fading ghosts of its own corona, rebuilt from captured history each frame.

Untouched native-resolution copies of the stills live under renders/native/. The dated, append-only diary of renders is the next section: what the machine looked like then, beside what it looks like now.

03 · DIARYWhat the machine looked like, and when

The gallery above always shows a subject's current state. This diary is the half that never changes: an entry is recorded once, on its date, and is never overwritten or deleted. Each group below follows one subject, newest first, and links back to that subject's current render in the gallery. Because every capture is deterministic, an entry is also a regression artifact: a loop that has drifted no longer matches its recorded self.

terrain-breach

1 entry · 2026-08-16 · See this subject's current render in the gallery.

flare-occlusion

1 entry · 2026-08-16 · See this subject's current render in the gallery.

04 · STATUSWhere the project actually is

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

The maturity ladder

The design is split into 88 blocks: 73 hardware, 15 software. Every block climbs a seven-rung ladder one rung at a time, and each advance must cite evidence that a validator re-checks against git history. Nothing is on the top three rungs, because those require a physical board, and there is none.

The fourteen blocks at RTL_VERIFIED are the whole console shell: command scheduling and DMA, the memory arbiter, guard and bridge, the video pipeline, input, audio, and the debug counters and per-frame checksums, each verified in simulation against its C++ reference. The thirty-three at UNIT_VERIFIED are the drawing machine and the world it draws: the five rasterizer blocks, the texture units and cache, the geometry front that clips and bins a triangle, the terrain blocks, the persistent damage store, the creature skinning block, the vertex projector, two particle blocks and the trace ring. That rung means the circuit design and the C++ reference agree on every case a test could put to them, in simulation. Six further blocks are marked blocked on hardware; the ledger tool refuses to advance them until a board exists, no matter what evidence is offered.

The creature path now exists as circuits

The machine could draw a world, but not an animal moving in it. That path is now designed and checked in simulation from end to end: a packed quaternion becomes a rotation matrix, bone matrices chain down a skeleton, a whole skeleton pose is decoded from one animation clip and frame, a cache decides which poses are already decoded and which one to throw away, and skinning makes a creature's vertices follow its bones. Each piece is compared against the same C++ reference the images above come from.

Two decisions inside it are worth stating. The chain multiply is built to compute one element per cycle rather than all of them at once, and the whole decode chain shares a single multiply engine across every bone, because posing is not per-vertex work: a pose is decoded once for a given creature type, animation and frame, and then shared by every creature of that type on screen that frame. That sharing is the entire reason the cache exists. The cache block, in turn, decides which pose is needed and where it goes while deliberately not owning the memory it sits in, because how much of the chip's fast memory to spend on posing is a real decision, and burying it inside a module is how a budget gets spent without anyone choosing. Until that is decided the pose block stays marked unfinished, because two verified halves are not a finished block.

A vertex on screen, and a division that had to be exact

Turning a posed vertex into a pixel position needs a division, and the circuit has to give the same answer as the reference down to the last bit, including how it rounds negative numbers, where the obvious approach is subtly wrong. No reciprocal trick reproduces it, so the block carries a real thirty-one step divider, pipelined so it still retires one vertex per clock. Its declared reference did not exist when the work started; the law turned out to be shipped under another name, already proven by the terrain block that uses it.

Around it, a run of smaller blocks landed the same way: the trace ring that records what the machine did for later inspection, the store that holds the scars burned into the ground, the two terrain blocks that bake a program's output into the surface and read velocity back out of it, a cache that keeps validated spell programs resident, and the two ways a particle becomes something drawable, a triangle when it is large and a point sprite when it is small.

The scar store had working circuitry and a green test suite for months and still could not advance, because the ledger looked at its test and called it an alias rather than evidence. It was right: the test imported the reference model, named it, and never called it, so it checked that the block agreed with itself. The replacement runs both over one stream of operations and makes them agree on every texel of a patch. The law it defends is the one the block exists for, that re-acquiring a patch does not wipe it. A version that cleared on every acquire passes any test that writes and reads in one go, and erases the world between frames.

The spell-program engine

Terrain programs and spells are compiled bytecode, and so far only software has been able to run them. The engine that will run them in hardware is under construction, and four parts of it are built and checked: an arithmetic core covering fifteen operations (add, multiply, compare, clamp, dot product and the rest) over 300,000 random cases; a reciprocal, which needs a 256-entry table and a correction step, over 150,000; sine and cosine, checked exhaustively, because an angle here is a 16-bit count of turns, so all 65,536 of them were compared for both functions, which makes that one a proof rather than evidence; and length and distance, resting on an exact integer square root done as binary longhand rather than an approximation, because a program's lengths have to match the software's at every input.

Both tables are generated from the reference by a script instead of being typed in, and then checked entry by entry, because a wrong constant would not fail loudly. It would put a few angles slightly off. An operation the engine cannot yet perform refuses rather than returning zero, because a quiet zero would let it run a spell it cannot actually evaluate and everything would look fine.

One engine unblocks five blocks, which is why it is the next substantial thing being built. The specification forbids a second implementation of the instruction set anywhere in the project, so this is a bytecode engine that executes the same program images the software interpreter reads, verified against that interpreter, rather than an evaluator written by hand from the prose.

What is left, and who it is waiting on

Every remaining block was trial-advanced one at a time and its objections written down, so the remainder is known rather than estimated. Two supplies have now run out: work that was finished but merely unrecorded, and blocks whose law was already written somewhere under a different name. The thirty-seven that remain split three ways.

• Waiting on a specification another part owns. The compressed vertex format has two ends and the packing end belongs to the asset tools. Inventing one end alone would create exactly the kind of unratified law this project keeps catching.
• Waiting on the spell-program engine. Five blocks, one engine, the one described above. Large, unambiguous, and needing nothing from anyone.
• Waiting on a decision about how the game behaves. Roughly a dozen blocks: how a particle spawns, ages and collides; what bloom and heat haze look like; what the interface sprite pipeline does. There is no software to copy and no ratified specification section to follow, so building them means choosing the behaviour first and recording that choice as the reference.

Finishing the hardware is therefore not one more sitting's work, and the page would rather say so than let a rising count imply otherwise.

Phase 2 closed: the console runs as one machine

Before Phase 2, every verified block had only ever been tested alone. Phase 2 composed them into one running machine: publish a sealed frame packet and the console fetches it, schedules it, copies the pixels, swaps buffers, scans out, and reports a per-frame checksum and counters, with no test scaffolding in the datapath. In the gate demo, two controllers move markers across a split-screen world through the real input path, and every one of 1,202 displayed frames matched the independent C++ reference over every byte. A randomized 10,000-frame soak (two and a half hours of simulated play) passed 205,026 checks with zero failures.

Composing the blocks revealed defects no per-block test could see: a data seam that silently carried only an eighth of each memory write, while its test compared exactly the eighth that survived; a deadlock between two blocks that are each correct alone; and both framebuffers sharing one DRAM bank, which shredded the display under real combined traffic. All three are fixed and pinned by tests.

The gate also measured that copying a finished frame off the machine for checking takes just under two frames, so debug captures run at 30 Hz. That number is the cost of the debug copy, not how fast the console draws.

Phases

The charter defines fourteen phases, each with a hard acceptance gate. Two have written, ratified gate reports.

The one outstanding Phase-1 gate (a tiny program in the console's own language parses, type-checks and compiles) was deferred into Phase 3, in writing, and Phase 3 is now underway. The amber marks on Phases 6 to 10 mean blocks belonging to that phase are verified in simulation, and nothing more: none of those phases has a written gate report, and no phase above 2 has been closed.

Tests and proofs

The fast gate every change must pass currently runs 214 tests with zero failures, having risen from 180 over one day of work. Beyond it: long randomized nightly soaks, dedicated memory and video lanes, and 216 compiler test cases. Excluding generated code, the hardware description is about 29,900 lines of SystemVerilog, beside 27,800 lines of TypeScript, 23,700 lines of C++ reference, runtime and tools, and 46,900 lines of C++ tests.

Ten properties are registered for formal proof, which is mathematical model-checking rather than testing. One of them is worth retelling. The memory arbiter's fairness bound was frozen at 40 cycles and cited as evidence for a full development wave, but the proof had never actually been run. The moment it was made real, 40 failed. The bound was re-derived from the actual burst arithmetic and then proven exactly tight: the proof fails at 51 cycles and passes at 52, so 52 is the true worst case rather than a number that happened to pass. The old formula stays in the spec, struck through, so the error remains visible. One property, the memory-refresh bound, is not established: its full proof does not finish on this machine, so it is excluded from the automated lane and recorded as unfinished.

First synthesis

Synthesis now reaches the console itself, one block at a time. Thirteen of the shell's eighteen blocks have been placed and routed on a stand-in Cyclone V part, and they come to 4,096 ALMs between them, roughly a tenth of that device. The largest single block measured is the command scheduler at 815; the smallest is the video mode decoder at 70. Five blocks did not fit and are recorded as failures rather than estimated: four ran past their time budget and one was stopped after asking for 28 GB of memory on a machine with 24.

That last number has since moved. Composing the whole shell used to commit 28.4 GB against 24 GB of memory and thrash at near-zero processor use until it was killed, so there was no composed run at all. Two staging memories were restructured, and analysis and synthesis of the composed shell now runs to completion and stops with a precise complaint instead: the toolchain names two memories it could not turn into RAM blocks, because both are read asynchronously, and reports that the registers left over exceed the device. One of the two was not known to have that defect until the tool said so. There is still no composed resource figure and none is guessed at, but the obstacle is now a named fault with a route through it rather than a machine that could not hold the problem.

No block is marked SYNTHESIZED. The device is a stand-in until a board is probed, every input and output in these runs is virtual, and a per-block fit says nothing about how the composed machine would route or close timing. There is no timing-closure data and no bandwidth data; those directories exist and are empty on purpose.

05 · 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.

• Board truth. Real memory timings, measured bandwidth, clock stability, input latency. The file meant to hold these measurements does not exist, by design. No probe result has ever been simulated or assumed.
• The MiSTer platform layer is not vendored yet, which blocks the clock, reset and clock-domain-crossing blocks.
• Timing closure, and resource figures for the composed machine. Individual blocks are now being placed and routed by Quartus against a stand-in device, which is where numbers like 70 ALMs for the video mode decoder or 222 for the audio FIFO come from. The whole shell is a different matter: composing it used to exceed this machine, at 28.4 GB of memory against 24 GB available, and now runs through analysis and synthesis only to stop on a named inference fault. Either way there is no composed-machine figure and none is guessed at. The real chip stays unknown until a board is probed, so every number here is a stand-in and no timing claim is made at all.
• The top three maturity rungs, for all 73 hardware blocks.
• The long soak tests: eight and twenty-four hours of combined stress on real silicon. Not runnable, and explicitly not simulated.

And what simply is not built yet

• The Wound Lab demo is barely begun. The charter specifies a full scene: an island, two player wizards, three creature species, four spells. What exists is its first thin slice, the Phase-2 gate demo: two controllers moving markers on the composed machine. The sigils in the renders above are 8×8 test patterns standing in for wizards.
• The hardware rasterizer exists in RTL, and has never run on a chip. All five of its blocks are written and each is checked against the C++ oracle it must match: the edge walker, the tile store, early-Z, the fragment pipeline and the RGB565 resolve, plus the composition that wires them into one triangle-to-framebuffer path. The texture cache and the sampler are written too, and so is the geometry front that clips a triangle, sets up its edges and sorts it into tile lists, which then drive that rasterizer for real rather than by hand. Three arithmetic cores carry machine-checked proofs. That is simulation and proof, not silicon: none of it has been synthesized as a composed machine and none of it has been programmed onto a device. Every image on this page still came from the software renderer, and no picture here was produced by that RTL.
• What is designed and what is still absent. The creature animation path is designed and checked in simulation, and so are the geometry front, the vertex projector, the terrain blocks, the persistent damage store and two of the seven particle blocks. Still absent entirely: particle simulation, the compositor, the interface sprite pipeline, and the hardware engine that will run terrain and spell programs. The pose block is deliberately marked unfinished even though both of its halves are verified, because the memory it should use has not been chosen. None of this has been synthesized or run.

06 · 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 circuit is written: an executable reference implementation, directed tests, randomized tests that compare the circuit against that reference, and formal proofs where a property can be stated. The command format is generated from a single definition into C++, TypeScript and SystemVerilog, and the three are held byte-identical by a test that fails on any drift. There is no floating-point math anywhere in the render path; the software renderer is integer-only precisely so hardware can match it exactly.

Breaking the hardware on purpose

Every new block now ships with a mutation sweep: the circuit is deliberately broken in a list of specific ways, and the test suite has to notice each one. A test that stays green while the hardware is wrong is not evidence, and the only way to find that out is to make the hardware wrong. The sweep has caught something in most of the blocks built most recently, and in every case the test had been passing.

• The skinning block exists to round once, at the end, rather than twice along the way; double rounding is off by one in the last place, which reads on screen as a silhouette that shimmers as a creature moves. That law was defended by thirty-nine directed checks that a double-rounding version passed completely, because every matrix in them was built from whole numbers and rounding early threw nothing away. The replacement sweeps every blend weight against deliberately awkward values, and the broken version now fails hundreds of cases.
• The pose cache's eviction test could not tell "throw away the oldest" from "throw away the newest". It checked both groups, so a backwards cache produced the same totals with the roles swapped, and passed.
• A projection test could not tell whether the block was reading the right camera, because the two split-screen views happened to differ only vertically. A version that always read the first camera horizontally gave identical answers.
• Two sections of a cache test asked for animation frames past the end of the animation, so every request was correctly rejected and those sections tested nothing at all. They looked green the whole time.

The sweep also keeps catching prose rather than circuitry. Four claims written into comments about why something mattered turned out to be false when the matching mutation changed nothing: a division that never truncates, a shift whose signedness makes no difference at these widths, a rounding order that is exactly equal except at the extremes, and a guard against a hazard that was not there. None of the four changed the hardware, and all four would have misled whoever read the file next.

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