The project, documented by its builder on The Tube Computer website and independently covered by Hackaday, Tom’s Hardware, and TechSpot, is a serious discrete-logic computer rather than a decorative valve panel. Its 920 individual triodes implement NOR logic, registers, counters, an arithmetic logic unit, clocking, and a small amount of tube-based memory. It is also a useful reminder of what a “computer” becomes when every abstraction normally buried inside a microprocessor is made visible, hot, and repairable with a stepladder.
What it is not is a rediscovered 1950s computer or a practical vintage PC replacement. The builder describes it as a modern 8-bit design made with old components, and its real achievement is architectural: reducing a general-purpose machine to a repeatable hardware building block that can be understood, debugged, and physically followed across a wall.
The flight simulator is written, but the output system is incomplete
The headline claim that the computer “plans to run flight sim” is broadly true, but the details matter. Mike says he wrote an Airship Simulator for his grandchildren, set around an imagined British R80 voyage from Brighton to Paris. A panel based on the R80 bridge uses membrane controls to send 5-volt inputs to the computer, covering ballast, gas release, engine power, elevators, rudder, and mooring gear.
The unresolved part is the status system. Mike’s own documentation says the computer should eventually send the airship’s X, Y, and Z values to a flight-sim panel through a STATUS instruction, but that subsystem currently has only one input and one output. His conclusion is unambiguous: “So no flight sim yet.”
That conflicts with the more definite wording in TechSpot and Tom’s Hardware, both of which described the machine as currently set up to run the airship simulator. Their reporting accurately captures that software, input hardware, and a simulator concept are present. But the builder’s account distinguishes a live input demonstration from the complete interactive simulation promised by the finished design. The difference is not semantic: without the planned status output, the user cannot see the full computed state of the simulated airship.
For anyone who has built an emulator, a microcontroller project, or a homebrew computer, this is a familiar failure point. It is possible to have working CPU logic, working code, and working controls while the system remains incomplete because the I/O path cannot reliably expose the program’s results. In this case, the core machine is only part of the job; the console must handle wide and varying voltage levels that its initial design did not accommodate.
Mike says the display console needs a complete redesign, potentially including Schmitt triggers and signal averaging. That is a more informative engineering story than the spectacle of glowing tubes: the machine is confronting an old systems-design rule that modern PCs conceal well. A processor can be logically correct and still be unusable if its interfaces lack isolation, conditioning, or dependable signaling margins.
A computer built from one gate type
The Tube Computer’s architecture is deliberately constrained. Each 6N3P is a double triode, so 460 tubes supply 920 triode elements. Mike uses them to construct NOR gates—the single universal logic function from which other Boolean operations can be built. The same approach underpins the machine’s counters, registers, arithmetic circuits, and control logic.
Hackaday noted the resemblance to the NOR-gate approach used in Apollo-era guidance-computer logic. The comparison should not be overstated: this is not a replica of the Apollo Guidance Computer, nor is it a preservation project. But the shared design lesson is real. A universal gate can reduce the number of circuit types a builder must design, manufacture, troubleshoot, and stock with spare parts.
That simplicity is valuable when the “chip” is a wall of thermionic components. The computer uses 46 plug-in boards with ten tubes each, connected through five backplane boards and mounted on a 190-by-130-centimeter acrylic panel. Mike says the machine is intended to make the instruction cycle visible to his grandchildren, rather than leaving computation as an invisible event inside a black package.
The processor has a 16-instruction set and an 8-bit arithmetic logic unit. Its basic operations include sum, carry, NOT, increment, and XNOR. A carry register permits larger-number operations by chaining bytes, so the machine can work with 16-, 32-, 64-, and 128-bit values even though its native datapath is only eight bits wide.
That is a legitimate form of general-purpose computing, but it comes with a severe performance cost. The control sequence uses six fetch cycles and one execute cycle, without pipelining. Modern x86 and Arm processors overlap many stages of work internally; Mike’s machine intentionally does not. Every instruction becomes an observable sequence of hardware events, which makes it educational—and extremely slow.
The awkward part is not the tubes; it is reliability
The Tube Computer takes roughly ten minutes to thermally stabilize after power-on, according to its builder. The tube filaments begin to glow from the side after about a minute, and the machine produces the “pleasant homely aroma” that made the rounds in recent coverage: dust burning off hundreds of hot glass valves.
That aroma is not a feature in any practical sense. It is an expected consequence of operating a densely packed collection of hot components, and the warm-up period is part of the reliability process rather than retro theater. TechSpot and Tom’s Hardware both report a 10-to-15-minute warm-up-and-reset procedure before use.
Tube life is another constraint. Mike’s Hackaday.io project page says standard 6N3P valves were originally rated for about 500 hours, with higher-grade variants rated longer. His supply includes old and recycled tubes that may have already accumulated unknown operating time, so failures are an operational certainty rather than an edge case. The project’s wall-mounted construction means replacing one can require climbing equipment as well as electronic diagnosis.
This is where the project differs sharply from a conventional retro PC restoration. An Apple II, Commodore 64, or early IBM-compatible machine may need capacitor replacement, storage media work, or a modern power-supply solution, but it contains integrated circuits that each perform a large amount of logic. Mike’s computer externalizes that logic into hundreds of heat-producing devices. A single weak tube, marginal connector, or poorly buffered input can turn into a system-level fault.
The builder acknowledges that the design needs continual adjustment and says he should have added more buffers to isolate controls from the functions they drive. That admission is one of the most useful parts of the project record. Buffering is often taught as a basic digital-design concept, but in a system operating with physical wiring, analog voltage variation, and tube logic, it becomes the difference between a stable interface and a setup whose behavior changes with heat and adjustment.
The “bang” happened on an earlier machine
The project’s most clickable detail also needs qualification. Mike writes that this Tube Computer “has behaved itself so far.” The two occasions it went “BANG” involved a previous tube-computer system, not the present 460-tube wall panel.
The earlier incidents are still relevant because they illustrate the risks that shaped the newer build. Mike recounts pulling plugs in panic after the first failure and says his wife later bought him a fire extinguisher after a second. The extinguisher remains part of his stated startup checklist.
But readers should not turn that anecdote into a claim that the current machine is routinely exploding or that the low-voltage design makes it a safe household appliance. Vacuum-tube projects combine heat, mains-powered supplies, stored electrical energy, fragile glass components, and potentially high voltages. Mike calls the machine “almost safe to touch,” which is better read as a warning delivered with humor than as operating guidance.
His design does make a notable compromise. The high-tension supply is kept below 100 volts, a lower voltage than many classic valve circuits use. That choice helps him place components closely and limits some of the danger associated with traditional high-voltage tube equipment. It does not eliminate fire, shock, component-failure, or thermal risks—and it may help explain why the I/O and signal-level behavior have needed more tuning than the initial plan allowed.
A useful demonstration of what integration changed
The Tube Computer’s value is not its speed, its supposed scent, or the promise of an airship game. Its value is that it exposes the hardware cost that semiconductor integration erased.
A modern Windows PC can execute billions of operations per second with CPU logic measured in nanometers, memory capacities in gigabytes, and I/O systems that users take for granted. Mike’s machine needs 460 valves, dozens of boards, a wall, a warm-up period, and ongoing manual adjustment to execute a small instruction set and eventually report a few simulated coordinates. The comparison is almost comically lopsided, but it makes the point better than a block diagram can.
The present build is a working computer in progress, not a completed flight-simulator installation. Its next meaningful milestone is not merely powering up another bank of glowing valves; it is finishing the status system and console redesign so that its airship software can present the state the CPU is already calculating.