LT6502: A 6502-based homebrew laptop
Alternate-history computing without post-80s advances
- Several comments imagine a world stuck at ~30–400 MHz CPUs and a few MB of RAM.
- Consensus: classic GUIs, productivity apps, CAD, Photoshop-style tools, and early web browsers would still exist.
- High-quality consumer video streaming and today’s social/video platforms likely wouldn’t scale, mainly due to bandwidth, not CPU.
- Some argue LLMs would be impossible; others suggest niche lab-scale ML on ASICs or early GPGPU-like hardware might have emerged.
- Many think multiprocessor and coprocessor-heavy designs (transputers, connection machines, Amiga-style custom chips) would be far more common.
Bandwidth, networking, and the “feel” of the web
- Strong disagreement about how “fast” 90s web browsing felt.
- One side recalls pages taking minutes to load over dialup/slow leased lines, especially with images.
- Others remember acceptable responsiveness on fast links, arguing modern sites feel no snappier due to bloat.
- Several note that slow links, not CPU, were the main bottleneck; early guidance even discouraged keepalives to avoid “wasting” backbone capacity.
- Alternate timelines discussed: mostly-text/gopher-like web, teletext/BBS/ANSI-style interfaces, or something like SymbOS/Newton OS as a refined low-resource GUI.
Ads, tracking, and web evolution
- Some imagine a low-power world with far fewer ads and tracking.
- Others push back: ads existed very early (Prodigy, AOL, early banners, DoubleClick), and if there’s any substantial internet, ads + tracking would appear.
- There’s debate over “young web had no ads”: others respond this was a short, pre-graphical era.
- Many distinguish JavaScript-the-language from modern JS-heavy app patterns; blame is placed on massive client apps and huge asset footprints, not JS itself.
Hardware, software bloat, and languages
- Several argue the big change wasn’t just faster CPUs but cheap RAM: once gigabytes were common, pressure to optimize vanished; Electron and huge web apps became viable.
- Others emphasize developer convenience and high-level languages (Java, Python, Ruby, C#) riding Moore’s Law; without rapid CPU growth, these might have stayed niche and C/C++-style efficiency would have dominated longer.
- There’s nostalgia for the 200–400 MHz era as a sweet spot: capable GUIs but constrained enough to prevent overcomplexity.
OS and UX nostalgia
- Classic Mac OS and System 7 are praised for extensibility and user-level customization (extensions, control panels), despite instability and cooperative multitasking.
- Comparisons are drawn with image-based/lisp/smalltalk systems for user empowerment vs. modern, more “locked-down” but stable and secure OSes.
- Some recall that mobile/embedded OS design (early iPhoneOS constraints) enforced efficient, focused software similar to the imagined alternate timeline.
Capabilities of 8-bit/6502-era systems
- Examples cited: web browsers on Amiga, early graphical online services (e.g., Prodigy), SymbOS and Macintosh-like GUIs on tiny RAM footprints.
- View that 6502 is an ideal teaching CPU: minimal but complete instruction set and predictable timing.
- Acknowledgement that even with such hardware, text-centric networks, BBSes, and teletext-like systems could provide rich communication and information.
Reactions to the LT6502 homebrew laptop itself
- Strong enthusiasm for the project’s retro aesthetic, thickness, and “pointless but fun” nature; multiple people say they’d love to buy or build one.
- Nostalgic comments: 6502 as a “first processor,” comparisons to Commodore/Atari/BBC Micro eras.
- Some technical curiosity and nitpicks:
- Why only 46K RAM in a 64K address space (IO/ROM mapping constraints, discussion of bank switching).
- How an 800×480 display works with so little RAM (answer: the controller’s own VRAM/terminal-like graphics).
- Mixed feelings about using a Pi Pico/ATmega and other much more powerful microcontrollers as support chips in a “retro” machine.
- Speculation about battery life, cassette tape storage, and whether such a device could meet strict freedom/RYF-style certification.