Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Yes, Linux really did boot on a physical Intel 4004-based computer. Dmitry Grinberg’s custom board reached a shell prompt after 4.76 days under its final optimized configuration. But the 1971 four-bit processor was not running a native Linux port: the 4004 executed a software emulator for a MIPS R3000-class CPU, and that virtual MIPS machine ran a heavily stripped-down Linux kernel and Debian root filesystem.
What “Linux on the Intel 4004” actually means
The most accurate execution chain looks like this:
Physical Intel 4004
↓
4004 machine-code emulator
↓
Virtual MIPS R3000-class CPU
↓
MIPS Linux kernel
↓
Minimal Debian root filesystem and shellThat distinction matters. The board’s only physical CPU is a genuine Intel 4004, and the instructions ultimately executed by that chip make a real Linux kernel operate. In the strict sense, however, this is not Linux compiled for and executing directly on the 4004 instruction set. Linux is running on the emulated MIPS processor.
Grinberg documented the project as Linux/4004, a system built for fun, art and experimentation rather than practical computing.
Why the 4004 cannot run Linux natively
The Intel 4004 was introduced in 1971 and is commonly regarded as the first commercially produced microprocessor. It was designed for calculator-style systems, not for a multitasking operating system.
#1 Best Overall
The 4004 processes four-bit quantities and has a 12-bit program counter, a four-level hardware return stack and a highly unusual external-memory architecture that relies on companion chips. It also has no native AND, OR or XOR instructions, only a carry flag, and no interrupt support. Its directly usable RAM is tiny by operating-system standards.
Linux expects a substantially richer processor environment: wider registers, arithmetic and logical operations, addressable memory, privilege and exception mechanisms, and an architecture for which the kernel has been ported. Rather than attempt an impractical native port, the project makes the 4004 emulate a processor that can run Linux.
Why MIPS was used
The virtual processor is a MIPS R3000-class CPU. MIPS provided a practical target for building a Linux kernel and a comparatively manageable architecture to emulate within the project’s constraints. There is no physical MIPS chip on the board. The MIPS processor exists entirely as software running on the 4004.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsEvery virtual MIPS operation must ultimately be broken into work the four-bit host can perform. A 32-bit register, for example, is not a native object for the 4004: it has to be assembled, manipulated and stored through many four-bit operations. The emulator also has to implement virtual registers, memory translation, instruction fetching and peripheral access.
The custom hardware behind the demonstration
This is not a stock 4004 plugged into an ordinary development board. It is a custom hybrid system combining vintage Intel MCS-4 components with modern memory and interfaces.
- Intel 4004: the physical CPU.
- Intel 4201: clock generation.
- Intel 4002: period-oriented RAM support.
- Intel 4289: memory and ROM control.
- EEPROM or ROM: firmware storage.
- SPI PSRAM: memory for the virtual MIPS machine.
- SD card: storage containing the Linux system.
- UART: serial input and output.
- VFD display and LEDs: visible output and an emulated program-counter indicator.
The board was designed as a wall-mounted art object, with through-hole parts, right-angle traces, no vias and a visible vacuum-fluorescent display. The creator reports power consumption of approximately 6 W for the board. That figure applies to this project’s hardware, not to every possible 4004-based replica.
How the system gets enough memory
The original 4004 memory arrangement is nowhere near large enough for Linux. The project therefore supplies the virtual MIPS computer with modern SPI PSRAM.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThe kernel is approximately 2.5 MB, so the first PSRAM device must be at least 4 MB. The project documentation says a shell can be reached without swap using about 4.5 MB of total RAM: a 4 MB chip plus a 512 KB chip.
The 4004 itself still has only a very small working area. Grinberg describes the board as providing 440 bytes of 4004 RAM when status nibbles are counted, or 352 bytes without them. That space holds virtual MIPS registers, translation-lookaside-buffer state, emulator bookkeeping and peripheral-control data.
More virtual RAM is not automatically faster. Linux must initialize and track additional memory, and the creator observed that increasing the virtual machine to 16 MB initially made boot slower.
Storage is also a bottleneck
Linux boots from an SD card accessed over SPI. A normal SD-card sector is 512 bytes, larger than the 4004’s available working buffer, so the system transfers data in smaller pieces directly between the card and PSRAM. The project documentation reports that reading or writing a sector takes slightly more than one second on the finished system.
The virtual Linux disk uses a paravirtualized disk driver rather than a full emulation of a historical SCSI controller and physical disk. That is an important design choice: this is a deliberately engineered combination of vintage processing hardware, modern memory and storage, software emulation and simplified I/O.
Why booting takes 4.76 days
At the 4004’s approximately 740 kHz operating speed, the project describes the emulated MIPS machine as running at roughly 70 Hz. The physical board was overclocked to approximately 790 kHz, corresponding to about 74.73 Hz according to the project’s calculation.
The resulting slowdown is not just a matter of comparing a 740 kHz clock with a modern processor. The 4004 is emulating a 32-bit CPU, and each guest instruction can require a large amount of host-side work. Memory copies, SPI transfers, instruction fetching, virtual memory management and Linux initialization all add overhead.
The reported 4.76 days means booting from the documented optimized configuration to a usable shell prompt. It does not mean that every Linux command becomes immediately usable afterward, and it is not a universal boot time for every 4004 configuration.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →The optimization path from 8.9 days to 4.76
The final result required extensive low-level optimization. Grinberg’s project notes describe the progression:
| Stage | Estimated boot time |
|---|---|
| Initial realistic emulation estimate at 740 kHz | Approximately 8.9 days |
| Lookup-table optimizations | Approximately 8.4 days |
| Instruction-fetch optimization | Approximately 7.25 days |
| Memory-copy optimization | Approximately 6.63 days |
| Further optimization | Approximately 4.81 days |
| Specialized instruction-fetch path | 4.76 days |
Several techniques made the difference:
- Lookup tables replaced logical operations that the 4004 does not provide directly.
- Lookup-table multiplication avoided expensive general-purpose arithmetic.
- SPI and memory-copy loops were unrolled.
- Specialized shift routines reduced repeated four-bit operations.
- The Linux kernel configuration was aggressively reduced.
- Unnecessary large-block-device support and associated 64-bit arithmetic were removed.
- Instruction fetching from SPI PSRAM received a dedicated fast path.
- TLB size was tuned for the actual workload.
- Hypercalls and paravirtualized I/O avoided the cost of fully emulating devices that Linux did not need for this demonstration.
The main engineering achievement is therefore not simply “making Linux boot on an old CPU.” It is fitting enough of a 32-bit virtual computer, its memory system and its peripherals into the 4004’s extremely constrained code and data resources.
What can the finished system do?
It can reach a shell and execute commands, but “can execute” is very different from “is practical.” Reported examples include:
- A directory listing taking roughly 16 hours to appear.
- A kernel-version command taking a similar amount of time.
- An integer-only ASCII Mandelbrot program completing in under nine hours.
- A floating-point Mandelbrot version taking approximately 30 days.
- Kernel compilation being projected to take years.
The guest runs at roughly 70 Hz at a 740 kHz 4004 clock, or approximately 14,030 times slower than real time according to the project’s description. The result is useful as an experiment, not as a workstation, server or normal Debian installation.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Was the result produced on real hardware?
Development relied heavily on a separate software model of the complete 4004 system. That allowed firmware changes and optimizations to be tested without waiting several days for every physical boot.
The final demonstration was performed on the physical 4004 board. The project video uses variable speed-ups for watchability, so it should not be interpreted as continuous real-time footage. The project page says the clock and calendar shown in the video were accurate. The demonstration video shows the hardware in operation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.There are real engineering risks
A multi-day boot is inherently fragile. A power interruption, component failure, memory error or timing problem can force a restart. Vintage chips can also behave differently from modern parts, while the modern memory interface must be made to work within the timing limitations of the host system.
The creator notes that the PSRAM timing implementation was initially off-spec by a large factor, although testing indicated that it worked under the project’s conditions. That is an engineering caveat, not evidence that the system uses a conventional, fully compliant memory interface.
Is this a completely 1971 computer?
No. The 4004 is the defining physical CPU, but the complete computer uses modern PSRAM, an SD card, EEPROM, UART circuitry, power components and a 32-bit virtual processor. Calling it a “4-bit CPU at the center of a hybrid system” is more accurate than calling it a completely period-correct 1971 Linux computer.
That also means “Linux on a stock Intel 4004” is misleading. The accurate description is Linux running on a custom computer centered on a real Intel 4004.
Could you build one?
In principle, yes. The project page includes technical documentation, source material and component information. In practice, replication requires scarce vintage chips, custom electronics assembly, careful debugging and modern memory and interface components.
The creator has discussed kit or limited prebuilt availability by inquiry, but this should not be confused with a routinely available commercial product. Vintage-chip prices also vary significantly with condition, provenance and supply. Historical figures listed in the project documentation—such as approximately $250 for a 4004, $50 for a 4201 and $70 for a 4289 on eBay USA at the time—are not current 2026 prices.
Free tools Windows power users keep installed
One-click scans. No signup required.
A modern emulator, FPGA design or microcontroller implementation would be dramatically easier and faster. It would also remove the defining challenge: having a real Intel 4004 execute the emulator.
The careful verdict
“Linux boots on the Intel 4004” is legitimate shorthand, provided it is immediately qualified. The physical 4004 executes machine code that emulates a MIPS R3000-class processor; that virtual processor runs a real, heavily stripped-down Linux kernel and Debian root filesystem. After extensive optimization, the system reaches a shell in 4.76 days.
It is not a native 4004 Linux port, a normal Debian installation or a practical computer. It is an extraordinary demonstration of emulator engineering, operating-system portability and how far software abstraction can stretch hardware that was never designed to run Linux.
For the implementation details, parts information and optimization notes, see Dmitry Grinberg’s Linux/4004 project page. Independent context is available from Tom’s Hardware and Ars Technica.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
