The ntsc bench
The pipeline from the repository, running in this page: NES dots are generated here, encoded to the composite waveform, pulled apart by the filter you choose, demodulated and matrixed, and the decoded frame is drawn. It is the same signal path the test suite holds, compiled to WebAssembly from the recorded commit.
This is a lab instrument that now runs near the signal’s own rate: at least 41.5 frames/s on the notch filter and 44.4on the three-line comb in one thread (perf-report run 2026-09-02, wasm+simd128 (the shipped bundle), node v24, Ryzen 5 5600X, low end of the spread over three fresh processes), after the speed work the repository’s perf report records. Step advances the source one frame. Run is a real free-run: the source advances at its own exact rate against the wall clock, the page encodes what it can, and the drift counters print what a real display would have duplicated or dropped, exactly as the repository’s pacing rules specify.
No frame yet. Step once, or run.
Three patterns, generated in-page from the documented dot layout (341 x 262 dots, colour and emphasis planes, parity alternating Even and OddShort). The hue bands are the frame the landing’s tube photograph came from; the stripes put everything at dot frequency, which is where a comb earns its keep over the notch; the solid frame is one flat colour, where the two filters should agree, and do.
Two filters are here because only two make sense for the NES: the notch and the NES-native three-line comb. The two-line comb is not, for the reason the landing gives: on this signal it cannot work, and the code refuses it outright, with the reason spelled out, rather than shipping a quietly worse picture.
The bundle is built from bb310f5 by our own build script, and the record carries the file hashes, so what this page runs is exactly what the repository’s suite measured.