An interactive-speed Linux computer made of only 3 8-pin chips

Original Article ↗ Hacker News Discussion ↗

Nostalgia and DIY Kits

  • Several commenters compare this project to classic 6502/1802 “Altoids-tin” style hobby computers and vintage mail‑order kits.
  • Some argue modern PC “kits” (ATX parts) aren’t the same as solder‑from‑scratch computers, though others point to modern educational kits that partially fill that niche.

Hardware Design and Form Factor

  • Debate over PCB finish: ENIG on USB contacts is criticized as wearing and corroding; lead‑free solder as plating is seen as more maintainable.
  • Multiple people want to build “circuit sculpture” or dead‑bug versions; the tiny pin count makes this tempting.
  • The clever reuse of three pins for both external RAM and SD (“after much thinking, the solution is obvious”) is widely praised as the standout hack.

Storage: SD vs SPI Flash

  • Some suggest replacing SD with 8‑pin SPI flash to keep everything in chips, but the author and others note:
    • SD’s built‑in protocol and FAT make file transfer easy (just move the card).
    • Raw SPI flash would require clips/programmers or extra board jumpers and more software.
    • Passive “SD to SPI flash” adapters don’t magically make a flash chip appear as an SD card.

USB vs Simple Buses

  • Long thread on the complexity of USB versus SPI/I²C/UART:
    • One side laments that a separate USB‑serial chip is now “normal” and dreams of a world where simple multi‑drop buses and Ethernet replaced USB.
    • Others counter that SPI/I²C are fundamentally for on‑board use: single‑ended, no hot‑plug, weak error handling, poor for cables.
    • USB’s fixed clock rates, PHY requirements, CRC, and hot‑plug behavior are defended as necessary trade‑offs for a robust external bus, even if they preclude easy bit‑banging.

USB Reliability and Debugging

  • Discussion of USB CRCs and bit‑error rates: 16‑bit CRC on bulk packets can still miss errors over huge transfers; USB4’s move to 32‑bit CRC is cited as evidence.
  • Practical debugging options (sniffers, oscilloscopes) are mentioned and seen as nontrivial.

Microcontroller Choices and 8‑Pin Rule

  • Commenters propose ultra‑cheap RISC‑V MCUs (e.g., CH32V003, CH570) with integrated USB or radio.
  • The project’s 8‑pin constraint disqualifies many parts (too few usable I/O pins, missing interfaces).
  • Some question the omission of certain MCUs; the author responds that many were evaluated and later added notes to the write‑up.

Emulation, Linux, and JIT

  • Some ask why not use native ARM/Linux or an FPGA soft‑core instead of MIPS emulation.
  • Constraints given:
    • No FPGAs in 8‑pin packages.
    • No mainstream Linux ports for Cortex‑M0‑class MCUs with SPI RAM.
    • MIPS is described as an especially easy ISA to emulate and JIT, compared to ARM, due to ARM’s PC‑as‑general‑register quirks and self‑referential constructs that complicate translation.

RISC‑V vs AArch64 Controversy

  • A long, opinionated subthread critiques RISC‑V’s ISA design:
    • Claim that it ignored well‑known software patterns, leading to missing or awkward addressing modes, bitfield operations, single‑bit branches, etc., now being patched with extensions.
    • Concern over fragmentation: either target a rich “future profile” few cores implement, or a small baseline that runs everywhere but inefficiently.
    • Strong preference expressed for AArch64 for “big and fast” cores, ARMv8‑M/AVR for smaller systems.
  • Counter‑arguments:
    • RISC‑V’s compressed instructions and simplicity are seen by some as major advantages (code density, easy hardware).
    • Others note growing standard profiles (e.g., RVA23) and argue it’s too early to declare a final verdict; history will show whether AArch64 or RISC‑V made the better trade‑offs.
    • The original critic replies that after a decade the lack of a truly competitive high‑end RISC‑V core is telling, and that mixing 16‑ and 32‑bit instructions complicates high‑performance decoders in ways AArch64 intentionally avoided.

Difficulty, Audience, and Educational Value

  • Several readers praise the write‑up as both a great project and a mini‑survey of tiny MCUs and Linux‑on‑almost‑nothing tricks.
  • Some argue the 8‑pin constraint makes the design more of an expert stunt than a beginner’s kit; a slightly larger package could allow audio, keyboard, and video with similar soldering difficulty.
  • The author replies that the artificial constraint is the point: removing it would make the project trivial and far less fun, but notes others are welcome to reuse the code in more expansive designs.

Miscellaneous Ideas

  • One commenter imagines this kind of ultra‑minimal Linux node as a building block for “real” serverless or IoT infrastructure, though details (costs, recycling, management) remain speculative and largely unexplored in the thread.