Tom’s Hardware first detailed the finished build on August 11, while PickentCode’s own Reddit posts independently establish that the device exists, is custom-built, and uses a commercially sourced miniature Stirling-engine kit rather than a bespoke engine. The maker had earlier described the project in the r/steampunk community as a computer fully powered by the engine mounted above it, then showed the completed ESP32-C3 CHIP-8 machine in r/arduino and other communities.
The result is a persuasive demonstration of how far low-power embedded hardware can be pushed. It is also more accurately described as a heat-to-electricity microcontroller demonstrator than an off-grid PC: the mechanical engine, generator, smoothing capacitors, custom power electronics, firmware choices, and deliberately narrow workload all have to work together before a game can render reliably.
The 150 mW Figure Is a System Budget, Not an ESP32-C3 Rating
The headline number needs careful reading. Tom’s Hardware reports that the model Stirling engine can produce 150 milliwatts, or 0.15 watts. That is the project’s available generation budget, not evidence that the ESP32-C3 itself consumes 150 mW continuously.
At the ESP32-C3’s nominal 3.3-volt supply, 150 mW works out to roughly 45 mA. That is a tight but plausible ceiling for a stripped-down microcontroller application. Espressif’s current ESP32-C3 datasheet lists typical 80 MHz consumption in modem-sleep, with Wi-Fi clock-gated, at 17 mA with peripheral clocks disabled or 22 mA with them enabled while the CPU is running. At 3.3 V, that corresponds to roughly 56 mW to 73 mW for the chip before accounting for external flash behavior, the OLED, keypad scanning, conversion losses, or the analog voltmeter.
That remaining margin is precisely why PickentCode’s choices matter. Wi-Fi and Bluetooth are disabled; an OLED backlight-like brightness burden is avoided because the device uses a monochrome OLED rather than a conventional LCD; screen brightness is kept low; and the program drops CPU frequency when it can. The maker reportedly runs the ESP32-C3 at 80 MHz for display updates and CHIP-8 opcode interpretation, then lowers it to 10 MHz in the idle portion of the main loop.
The 10 MHz detail is technically credible. Espressif’s ESP-IDF power-management documentation identifies 10 MHz as the lowest frequency at which the default 1 MHz reference tick can be generated on the ESP32-C3. The same documentation supports dynamic frequency scaling, allowing firmware to reserve faster operation for active work and slow down when it is waiting.
What has not been published is just as relevant: there is no disclosed voltage-and-current trace, no sustained runtime figure, no generator model number, no measurement methodology, and no indication of how the system behaves through a long game session as the flame, engine speed, and electrical load change. The visible analog meter monitors voltage, but voltage alone cannot show whether the engine is continuously supplying the load or whether capacitors are temporarily covering short demand spikes.
That does not invalidate the project. It sets the correct boundary around the claim: PickentCode has demonstrated a working computer powered through a Stirling-generator arrangement, but the reported 150 mW should be treated as a design constraint rather than a lab-verified, end-to-end efficiency result.
The Capacitors Are Doing Essential Work
A miniature Stirling engine does not behave like a regulated USB power bank. Its speed varies with the flame, the hot-side and cold-side temperature difference, friction, generator load, and any momentary disturbance in the mechanical cycle. An ESP32-C3, by contrast, expects a supply that stays inside its operating voltage range and can tolerate abrupt current changes as code runs, flash is accessed, the display refreshes, or GPIO activity changes.
Tom’s Hardware reports that capacitors are wired into the circuit to stabilize generator output. That element is not decorative electrical cleanup; it is fundamental to the machine operating at all. The capacitors provide a small energy reservoir, absorbing some variation from the generator and releasing it when the digital electronics briefly draw more current than the engine can instantaneously deliver.
The arrangement likely has a basic but important division of labor. The Stirling engine provides mechanical rotation. A generator converts that rotation to electricity. The power circuit conditions the output, and capacitors smooth it enough to keep the logic supply from sagging during normal changes in workload. The creator’s front-panel switches then separately control the main circuit and the voltmeter, keeping the measurement display from being an always-on tax on the limited budget.
This is where the build has more engineering substance than a novelty enclosure around a battery-powered dev board. A battery would conceal transient demand and make the engine largely theatrical. PickentCode’s published description instead places capacitors directly in the power-stabilization path and frames the device around the engine’s extremely limited output.
Still, a capacitor-assisted design is not the same as a capacitor-free one. If the system can stay alive only because stored charge bridges repeated deficits between load and generation, it will eventually brown out. Demonstrating stable, indefinite operation would require showing that the average electrical demand, including conversion losses, stays below average generated power across the engine’s usable speed range. Neither the Reddit posts nor Tom’s Hardware’s reporting establishes that duration.
Why CHIP-8 Is the Right Computing Target
The software target is a large part of why this machine can exist. PickentCode is not emulating a vintage PC, booting DOS, or attempting to run Windows on an ESP32-C3. The device executes a custom CHIP-8 virtual machine, which is a compact interpreter for the simple 1970s virtual architecture associated with systems such as the COSMAC VIP.
CHIP-8 is exceptionally well suited to a build constrained by both power and display bandwidth. Its instruction set is small, its memory needs are modest, its graphics are normally based on a 64-by-32 monochrome display, and its games were designed around low input counts and simple timing. A 128-by-64 monochrome OLED gives the project enough pixels to present a crisp scaled-up CHIP-8 image while retaining space for its own interface conventions.
The 16-key keypad is another historically appropriate choice. CHIP-8 traditionally uses hexadecimal-style input rather than a full PC keyboard or gamepad. That avoids USB host hardware, Bluetooth pairing, radio power use, and a more complex input stack. The machine reportedly also includes a code editor that lets a user enter CHIP-8 opcodes and execute programs directly, turning the project into a small standalone programming environment rather than a fixed-function game prop.
The distinction matters for anyone tempted to compare the stated 80 MHz figure with desktop CPUs. The ESP32-C3 is a 32-bit single-core RISC-V microcontroller capable of clock speeds up to 160 MHz, but clock speed says little about its suitability for general-purpose operating systems. Its 400 KB of SRAM and embedded flash-oriented design put it in a different class from an x86 PC or a Raspberry Pi-class Linux board. Here, 80 MHz is not evidence of desktop-class performance; it is a carefully chosen operating point that leaves enough power for the display and keeps a simple interpreter responsive.
The Engine Is Real, but It Is Not a Steam Engine
The machine’s visual language leans heavily into Victorian steampunk: wood casework, painted tubing, exposed mechanism, a front-panel analog meter, 3D-printed parts, and etched references to Robert Stirling and his 1816 patent. Tom’s Hardware reports that PickentCode planned the layout in Blender, built the case from wood, used a DIY laser engraver for the side-panel artwork, and printed structural parts, housings, and keycaps.
But the engine itself should not be confused with a steam engine. A Stirling engine is an external-combustion heat engine. Heat is applied outside a sealed working-gas system, creating a temperature difference that drives expansion and contraction cycles to move a piston and flywheel. It does not need a boiler, does not send combustion gases through the engine cylinder in the way an internal-combustion engine does, and does not inherently use steam.
That correction may sound academic, but it has practical consequences. The machine requires a maintained heat source and a cool enough side of the engine to preserve the temperature differential. Its real fuel system is whatever provides the heat: flame, alcohol burner, gas burner, or another thermal source. It is therefore independent of wall power and batteries during operation, but it is not energy-free or maintenance-free.
PickentCode told a Reddit commenter that the computer was custom-built while the engine itself came from a kit ordered from China, with similar variants widely sold through marketplace listings. That makes the project more reproducible than a one-off precision-machined engine, although the lack of a published bill of materials, schematics, firmware repository, generator specification, and measured power data means it is not yet a reproducible recipe.
The Real Lesson Is Aggressive Power Budgeting
The lasting value of this project is not that a flame can run Pong. That was always physically possible. Its value is that it makes the often invisible discipline of embedded power budgeting impossible to ignore.
The CPU is slowed. The radios are shut down. The display is dimmed. The workload is kept deterministic. Input is simple. The screen is monochrome. The power source is buffered but not replaced by a large battery. Every subsystem has a visible cost because the engine produces only fractions of a watt rather than the hundreds available from even a modest PC power supply.
For Windows users and PC builders, the contrast is useful. A desktop machine can waste more power in standby circuitry, RGB lighting, USB charging behavior, or a single fan than this entire computer is reported to have available. PickentCode’s build compresses the computing stack down to its essentials: read input, execute a small program, redraw a small screen, and avoid every feature that does not advance those jobs.
The project is not a path to a fire-powered Windows handheld, nor is it an alternative to a battery-backed emergency computer. It is a successful proof that a carefully selected microcontroller workload can be made to coexist with an extremely weak and variable generator. The next meaningful update would be a measured electrical log showing sustained voltage, current, and runtime while a CHIP-8 game is actively rendering—because that would turn an impressive working build into a documented low-power engineering result.