A Reference Build: Playing a Game on a Spinning Disc

In May 2026 Hackaday published an article under the headline “CRTs Are Too Mainstream, So Game On A Mechanical TV Instead”. It covered a British YouTuber, working under the name smill, who had bought one of the kits documented in this dive and used it to play — and, by the video’s title, finish — Minecraft. The video is “I beat Minecraft on a pre-WW2 mechanical television”.

It is worth a volume of its own for three reasons. It is the closest published precedent to what this dive is building toward; it locates the difficulty of the project exactly where this dive has located it; and its coverage contains one factual error about the standard that is worth correcting carefully, because getting that number wrong would prevent a machine working at all.

A note on sourcing before anything else. The video itself could not be viewed during this research pass — the research tooling used here cannot read YouTube pages, and only the article’s account of the build, plus the search-result summaries of the video, were available. Everything attributed to smill below is therefore the article’s description of his work rather than a first-hand account of it, and is phrased that way.

6.1 What Was Built

The hardware was not custom. The article is explicit that this was a commercial kit rather than a scratch build: the same MindSets Online reproduction of Baird’s design, working on the Nipkow principle — in the article’s own description, a flat disc with a series of holes in a spiral, converting a single lamp’s brightness variations into a monochrome image. Thirty-two holes for thirty-two lines. The article’s aside on that point — “At least they’re not interlaced this time” — is a joke at the expense of the broadcast-television standards its readership normally deals with, and a fair one: progressive scan is one of the few things NBTV makes simple.

The work was all on the signal side, and the article says so in a sentence that could serve as this dive’s thesis:

“Getting a video signal from the computer to the LED in the televisor kit was the hard part of the hack.”

The approach, as described, was to write a small program that chopped the game’s images into exactly the pattern of brightness the television expects, and then send that pattern out as an ordinary audio signal down a cable — which the televisor treated as though it were receiving from an old radio. The article also points readers at video2nbtv as a tool that can do the same job, noting that the narrow-band television signal used by amateur radio enthusiasts has timing and modulation compatible with what the kit needs.

6.2 The Correction: 15 Frames per Second Is Wrong

The article states that the kit runs “32 lines at 15 FPS here”.

It does not. The NBTVA club standard, verified directly against the association’s published Chapter 25 for Vol 3 of this dive, specifies 12.5 frames per second — 32 lines, 400 lines per second, one frame every 80 milliseconds. The same figure appears in the association’s historical tables for the Baird and TeKaDe standards, all three of which ran at 12.5 frames per second.

This was noticed at the time by the article’s own readership. A commenter posting as ZXGuesser corrected it in the comments, giving 32 lines at 12.5 fps and citing the association’s standard. The correction is right and the article’s body text was not amended.

The error is small in print and large on a bench, which is why it is worth spelling out rather than noting in passing. The kit’s disc has no independent speed reference (Vol 2): its motor is dragged into step by a phase-locked loop comparing the sync pulses in the arriving signal against the pulses coming back from the disc. Generate a signal at 15 frames per second and the loop is being asked to hold the disc at 15 revolutions per second, 480 lines per second — 20% fast. Depending on the loop’s capture range it either fails to lock at all, or locks at a speed that makes the aperture spacing wrong and the picture unreadable. There is no partial credit; the number either matches or the machine does not work.

Two general lessons sit underneath this one. The first is that popular technical coverage of a niche standard is a starting point and not a source — the correct figure was one page away on the association’s own website, and the comment thread found it within a day. The second is a methodological one this dive has followed throughout: where a number governs whether hardware functions, it gets checked against the body that publishes it, not against the article that repeats it.

6.3 Why Minecraft Was a Good Choice

The article calls Minecraft “the new generation’s DOOM” — the thing people port to unlikely displays. That is true and slightly undersells how well suited it happens to be to this particular display.

Vol 4 set out what 32 lines by roughly 50 elements can actually carry: strong tonal separation, large shapes, clear silhouettes, and motion. It cannot carry fine texture or small detail. Minecraft’s visual language is, by construction, large flat-coloured blocks with hard edges and high contrast between sky, terrain and structures. It is close to being pre-optimised for a low-resolution scanned display in a way that a photorealistic game emphatically is not.

There is a second advantage that has nothing to do with rendering: the player controls the framing. A television signal fed from broadcast material gets whatever shot the director chose, and Vol 4’s constraint — that only close-ups and waist-up shots read — is imposed from outside. A player can walk closer to the thing they want to see. Interactive content adapts to a bad display in a way that recorded content cannot.

6.4 What It Teaches This Dive

Four things carry over directly.

The display is the solved problem. A commercially available kit, assembled from a box, was sufficient. All of the invention went into producing the waveform. That is a useful reallocation of expected effort for anyone planning this work: budget time for signal generation and software, not for optics and mechanics.

A live source needs a live path. A game is not a file. video2nbtv converts existing clips into wave files (Vol 4) and cannot, by its nature, serve a source that is being generated in real time. The route taken here — a bespoke program producing samples continuously — is the route Vol 5 describes, and this build is evidence that it is within reach of one person writing modest code.

Writing a purpose-built encoder is reasonable. With the standard’s parameters in hand, converting a frame buffer into the required raster order and adding sync is a contained problem. The existence of general tooling does not make a specific encoder redundant, particularly when the source is unusual.

Continuity is the risk the article does not mention. The article says nothing about latency, buffering or what happens when the game stutters, and the underlying constraint from Vol 2 does not go away for not being discussed: lose the signal for a moment and the loop loses lock, costing several seconds of rolling picture while it re-acquires. Anyone repeating this should assume that a loading screen, a garbage-collection pause or an alt-tab is a visible, multi-second event on the televisor, and design the buffering accordingly.

6.5 On Colour, Briefly

The article notes that the kit is monochrome and that a colour version of the project would need a different, 3D-printed set. This is consistent with the hobby’s wider practice: colour NBTV exists, the association’s own standard refers to a handbook chapter on compatible colour NBTV, and colour on a disc is achieved by scanning the same picture through filters rather than by anything the monochrome kit could be adjusted into. It is not an upgrade path for this kit, and this dive treats it as out of scope.

No image from the Hackaday article or the video is reproduced here: both are ordinary copyrighted works, and no licence covering republication was identified. The article is at hackaday.com/2026/05/12/crts-are-too-mainstream-so-game-on-a-mechanical-tv-instead/ and the video at youtube.com/watch?v=9-0OKkkqMc0.

6.6 Cross-References

• The lock behaviour that makes a stuttering live source expensive: Vol 2.
• The frame-rate figure this volume corrects, verified against the association’s own standard: Vol 3.
• Converting clips, and why a converter cannot serve a live source: Vol 4.
• Building the live path, with the sample-rate arithmetic and buffer rules: Vol 5.
• The open item recording that the video itself was not viewed: Vol 8.