The 100 Year Computer
We look back at older computers with rose tinted spectacles, but can we look forward with them? What might a computer with a 100 year lifespan look like, and how do we build it? In this issue I want you to rethink what we know about retrocomputing in terms of designing long-term sustainability today. Along the way I’ll introduce something I’m calling Heirloom Computing. This is part of a series I’m writing on the next 100 years of computing called As We May Link.
I’ve written a followup piece that has more info on what I’m building and answers some common questions.
The best way to read Tales From The Dork Web is via email. Sign up below to try it.
This issue’s music is by Hammock, a Nashville-based duo. You’ll want to play this and keep it running after you finish reading. This issue’s photos are peoples’ family photos from various times and places and prototype photos I’ve taken. I pushed right up against Substack’s limits with this issue. I’d love to add more links to definitions but I can’t. I’ll add missing links, definitions and resources in the next issue.
Grow, Grow, Grow Your Bloat
William Gibson said, “The future is already here, it’s just not evenly distributed.” He’s right. On opposite sides of the Pacific ocean, buying Cyberpunk 2077 is more or less the same. Upgrading it is a completely different experience.
What is it that makes computing so bloated? It’s easy for me to say ‘Electron’. 20 years ago I could’ve said ‘Java’ or ‘Shockwave Flash’. Newer software tends to grow bigger. Newer systems tend to be faster. If I run Windows 98 on a 10 year old computer it’s lightning fast. If I run it on a computer from 1998 it’s much slower.
Even though it’s over 20 years old, Windows 98 could meet up to 75% of general purpose computing needs. Windows XP, maybe 95%. Is a Windows 10 PC worth the jump from XP? I wouldn’t edit 4K video in XP but for the most part I’d say no.
There are only so many features a program can add until something becomes just good enough. At this point new features add less and less value. At some point people stop wanting to pay for upgrades. This happened with Windows XP, 1Password, even to some extent with the iPhone. What started my departure from Apple’s ecosystem was ditching the 3.5mm headphone jack. I know people who held on to 1st gen iPhone SEs for as long as they could because of the 3.5mm jack. The iPhone reached it’s apex. After that, every new feature added was worth less than the features taken away.
If the perfect iPhone was the 1st generation iPhone SE, why not stick with it? Why not improve sustainability or repairability? Because Apple’s share price is dependent on selling more devices each year. This perverse incentive goes way beyond tech.
To make green line go up for do gooder quarter, tech firms look to recurring revenue streams. New software is sold or better, rented to keep vendors in business so the cycle can continue. To justify payment, features are added regardless of whether they’re needed. Old features considered commercially unsustainable are removed, regardless of whether users need them. The Software-as-a-Service model too easily leads to forms of rent seeking. Tyler Cowen discusses the economics of rent seeking in depth above.
The true cost of an M1 Macbook is never fully realized. It'll never include the full environmental cost of production through the supply chain. It'll never include the full cost of recycling what it replaces. If dropping nearly $3000 on a new Mac made you 3000x more productive it might even be worth that total cost. But it won’t.
There are two reasons to replace a computer. One is an artificially amplified desire for something exciting, new and shiny. The other is the failure of software to run in under 8Gb of RAM. We call this replacement an ‘upgrade’, when what’s really happening is a celebration of sustainability failure.
Buying a new M1 Mac might make you feel excited, even happier for a moment. That’s a different value proposition. The glowing reviews imply something exciting is happening. You might feel like you want to be part of it. You probably don’t want to know the human cost of electronic devices. All you wanted was to run Slack without spinning beachballs showing up. If you do want to know more, The Unlockr nails it.
Software rent-seeking helps push hardware into landfills and exploited children into early graves. It does this to make green line go up for do gooder quarter. No individual app does this. Not every SaaS app is rent-seeking. But the software rent-seeking ecosystem as a whole is bad and we need to stop enabling it.
The Heirloom Computer
We could approach computing completely differently. Currently we build software to fill new hardware. We build hardware to provide capacity for new software. What if we focused on improving sustainability for that which was already ‘good enough’? What if instead of designing computers with 5 year lifespans, we designed them with 50-100 year lifespans?
My favourite computer is my Commodore Amiga 4000. It was my dream machine growing up. I do stuff on it that nobody in their right mind would do, from hanging out on Telegram to modeling COVID stats. But even my nearly 30-year old Amiga was never designed for a 50, let alone 100 year lifespan. The Amiga uses custom chips that were last made in the 90s. To design something with a 100 year lifespan we must think very differently about a computer’s use and role.
We used to use computers mostly offline. At home we'd play games, look up facts, write letters, store recipes, maybe a small inventory. Most would buy (or copy) programs. Some would write their own. Today we do most of this but the systems are permanently online. This convenience comes at a cost. Outages cut off access to data that should’ve been local. Exporting information can be difficult, if not impossible.
We could make offline-first software if we wanted. What stops us is inconvenience. Not for users, but for vendors. It’s inconvenient to not get reliable telemetry, tracking or monetisation data. When computers are always online, they’re at risk of attack. When computers are assumed to be always online, network failure is catastrophic. For a machine designed to outlive it’s first owner, always online isn’t an option.
An heirloom computer would feature a very different kind of planned obsolescence. It would evolve with a family over time. Such a device made today would look very different in 100 years. We could source parts from scrap technology using what's already available. The closest thing to slave labour for an heirloom computer is a child forced to do homework on it.
If we can’t expect to be always online, an heirloom computer must be offline first. It would be distraction-free. It would be a home for family documents. A place to store recipes, in-jokes and stories. It wouldn’t be the only computer in the family. There would be faster computers around, but it could become a family’s digital garden.
When your children are expecting, they could keep a journal for it. Their notes linked back and forth across yours would build an intimate story of family life. Your youngest child’s wedding, the funny things your grandchild asks their mother. One day that grandchild may write about your funeral. It’ll be a sad day and the heirloom computer might go away for a while. A few years later they’ll boot it up only to find almost every bad joke their dad told them came from you. An heirloom computer would become home to digital ghosts telling people they never met stories about who they are.
No matter what a marketing campaign may tell you, these aren’t moments to put in an app that might last a decade. This is a family’s personal history, passed on from generation to generation. It’s all the things you had as a kid that you’ll never be able to pass on. It’s all the things you’ve forgotten from those growing up around you who are no longer with us. One day you’ll be gone, and people who never met you will learn about you through an heirloom computer.
Designing For Longevity
Most software has bugs. Bugs arise when code encounters incorrectly structured data. The software fails to validate data before processing. This leads to crashes or worse.
For longevity, bug free software isn’t realistic. We can’t guarantee a system will receive updates. Nor can we be sure someone will apply them. Instead, good long-term software should degrade gracefully. We should expect faults. Failures should be swift but recoverable. Software should be small and simple. A simple tool that does one thing well is probably better here than a complex tool trying to do too much.
Hardware design processes change over time. We can't make some custom chips because the manufacturing processes no longer exist. Regulatory rules on the use of lead solder shifted industry to lead-free solder with shorter lifetimes. As we push for new manufacturing processes, we often lose older ones. Our right to repair is being erased both through the laws of the land and laws of physics.
We should acknowledge that hardware will fail over time. Good hardware, like good software should degrade gracefully. A 100 year lifespan system may have several decades without access to a usable display. Keys and drives may not work. We should expect years, if not decades to pass without the system being used at all.
If we accept that hardware fails, systems need more than spare parts. Over a 100 year lifespan, some parts will no longer be made. Some parts won’t be invented for 75 years. A loss of parts access cannot lead to a loss of capability. Our 100 year computer needs to be able to run on different systems with differing hardware of differing reliability.
One way to achieve this is to virtualise a low-overhead environment.
I tried this several years ago designing a Chip-8 handheld prototype. The Chip-8 was a virtual machine that never physically existed. RCA used it to create pong-style games consoles in the 70s. By virtualising a simple design, we can extend it to our needs. This is the software version of drilling holes in old iPhones to add headphone jacks.
Because we need to extend, repair and replace parts, a 100-year lifespan computer cannot be a black box. It’s design must be open. It must use open protocols and buses. Whatever we build today will be retrocomputing tomorrow at best.
My open sustainable computer acronym salad contains PS/2, VGA, SPI, TWI and UART. In plain English, each is an open standard with hand-solderable connectors.
If our computer’s SPI-connected SD Card slot dies we could make a replacement from a broken digital camera’s connector. In the worst case we could solder an SD Card directly to the computer. SD Cards won’t last 100 years but the code to talk to one will. For new forms of open storage, we could create adapters. This happens today. My Amiga predates it’s high capacity Compact Flash cards by years.
VGA support merely needs 3 resistors, a connector and a hard drive cable. Should AR contact lenses become mainstream, people will find ways to connect VGA devices.
Slower speed serial interfaces are degradeable, simple and work with everything. USB connectors won’t stand a chance on our timelines. How would input work without USB? The older PS/2 standard is fine. If connectors are unavailable we could cut a cable and wire directly to the device. When keyboards are no longer used, whatever replaces them could connect via a PS/2 adapter.
But what of software? What kind of OS would it use? What kind of CPU would it need? How much RAM?
The CollapseOS project has interesting views on this. It explores computing through the prism of complete ecological collapse. Their Operating System uses the Forth language running on older repairable systems. I admire a great deal about CollapseOS. While heirloom computing may share some ideas, it's not quite the right fit. I find it too steep a hill for a family computer to climb.
CollapseOS does uses a Forth-based virtual machine. With Forth’s minimalism a wide variety of platforms can be easily supported. For me, Forth alone is a little too minimal, but CP/M isn’t.
Gary Kildall's Control Program for Microcontrollers (CP/M) came out in 1974. By 1981 CP/M became a de facto business standard. If it wasn’t for a deal between IBM and a small Alberquerque-based outfit CP/M would’ve stayed popular into the 90s.
It’s MS-DOS-like, and software is still released today. It’s extendable with plenty of programming languages and professional applications. It doesn’t assume Internet access, but forms of connectivity are possible. If Windows XP can meet 95% of someone’s general purpose computing needs, CP/M could fulfil 40-60% at a slower pace. Don’t expect to edit 4k video on CP/M. Professional Spreadsheet, Word Processing, and even professional database applications are available.
Emulating CP/M requires more grunt than a standalone Arduino Uno. Jeelabs already ported CP/M 2.2 to an STM32 microcontroller. STM32 chips are everywhere. You’ll have some in your laptop, in your car, in your screen, in your phone, maybe in your washing machine. The ESP32 is another IoT-friendly candidate. We should be able to target anything with capacity as long as a common hardware baseline exists.
Work on ESP32 VGA support has already been done by people far smarter than I, like Bitluni and Fabrizio Di Vittorio. Fabrizio not only got VGA working. He built a beautiful multisession CPM Plus implementation that does 80% of what I’d hoped for.
Now I have a concept for an open heirloom computer built and maintained from recycled parts. I guess I should build one.
A First Attempt
When I started sketching out the concept in late 2019 I thought I'd have this ready in 2020, so I called it ZX20. I forgot about another adage, Hofstadter’s law:
It always takes longer than you expect, even when you take into account Hofstadter's Law
I built a BASIC interpreter with working graphics and sound. Then I learned the hard way why BASIC is a bad move. Every BASIC implementation is only semi-compatible with every other implementation. I could write programs, but there wasn’t much else I could use. I emulated a ZX Spectrum for a while, but it didn’t move towards my goals. Then I saw Fabrizio’s Altair 8800 simulator and realised CP/M might be an option.
CP/M isn’t a fantastic Operating System. It’s clunky and basic. It’s just good enough to get the job done. You could learn it in 10 minutes and master it in an afternoon. Although CP/M has it’s own filesystem, Fabrizio’s version uses regular files on an SD Card. It also has other features making it easier to use than a regular CP/M computer.
CP/M runs in 64k of RAM with disks of between 88 and 360kb in size. I run it on a 64Gb MicroSD Card. Current designs are single-board but I'm building an RC-2014-style backplane next. This reduces the amount of full prototypes I need to build. Once complete, a fully stacked system could feature:
Core CPU board (ESP32 or STM32F4) + Serial
VGA-connector-based graphics
Storage (SD Card via SPI bus)
Optional Audio (up to 2x 3.5mm Jacks or RCA plugs, a TBC DAC and ADC and TBC controller to handle sound over I2S or SPI)
Keyboard, and optional Mouse (1-2x PS/2)
I/O Extender (SPI, I2C, MCP23017 and 2x 9-pin DSUB Atari compatible Joystick ports)
So far I’ve breadboarded and built single-board prototypes for each except the GPIO extender. COVID and Brexit aside, next year should see the first full prototype.
I talked about it with friends. Saumil Shah over at RingZer0 training asked me to build something for people who helped him this year. As you read a few people have Retro Zer0 computers in their hands or coming their way.
While my partner and I started building boards I wrote a quick 60 page manual. I can’t share my SD Card but I can share the manual, designs and more. The Retro Zer0 is not something you can buy but I’ll open source everything about the ZX20 project.
If you want to buy a product, please buy Fabrizio Di Vittorio’s FabGL board. He built something that let me mostly skip from idea to proof-of-concept in one leap. My designs lean heavily on his. If you want to build one yourself I’ll have KiCAD drawings and more up by the next issue.
The Retro Zer0 is not the ZX20 but shares DNA. I’d like to thank Saumil Shah and RingZer0 training for the opportunity to fund some of this exploration. I’d also like to thank Fabrizio Di Vittorio, to whom I’m endebted through his work.
You can follow the project with the #ZX20 hashtag on Mastodon and Secure ScuttleButt. The best way to try this out is to run a CP/M emulator full-screen. Udo Monk’s Z80Pack is the reference CP/M emulator, although MockbaTheBorg’s RunCPM is also worth a look. MockbaTheBorg’s CP/M runs an older older version than Fabrizio Di Vittorio’s CP/M Plus. The project’s Github page links to an extensive software library that should work on both. It also supports files on the filesystem rather than CP/M disk images. This means you could start with RunCPM, build an heirloom computer later and transfer to the board when you finish. If you just want to try CP/M in a web browser Stefan Tramm’s emulator setup is minimal but functional.
I’ve not seen anyone using the term heirloom computing as I have here. Nobody owns this term. I encourage you to think about your own ideas of what heirloom computing might be and to realise them if you can. What might more sustainable mainstream computers look like? Could we move the CPU to a secondary controller, only used when a lower power CPU needs it? Could we make more sustainable communication devices by making phones do less? You don’t have to be trapped in Wintel hauntology.
My approach may lead to a dead end, I’ve already found two this year. 100-year computing might not even be possible with today’s parts. That’s the beauty of it. I can plant the seed of 100-year computing now but I’ll never get to see how tall the tree may grow. I just hope that in the future people will find ways to enjoy the shade.
If you’ve enjoyed this you might like the followup piece I wrote on what I’m building with answers to common questions.
Things You May Have Missed
Techtinkering shows you how to get up and running with Udo Monk’s Z80pack. Mike Hoye has an excellent essay on the origins of null character-based string termination. Vega Deftwing’s Opinionated Guides is a packed digital garden I’m reading through.
Hype Machine built a page that gives you bandcamp links from a Spotify playlist so you can support your favourite artists more directly. Oona’s written an amazing article about patterns in records and fantasy record players.
Scary Pockets are the funkiest thing I’ve heard since Vulfpack’s it gets funkier. Thanks to Craig Butcher I’m leaving you with the funkiest Eleanor Rigby cover I’ve ever heard.
I’ll leave you with a quote from Nicholas Sparks’ A Walk To Remember.
There are moments when I wish I could roll back the clock and take all the sadness away, but I have the feeling that if I did, the joy would be gone as well.
If you’ve enjoyed this issue, please do share it with your friends. If you’d like every issue in your inbox, you can sign up below. I’ll return in two weeks with more Retro Zer0 pictures and more Tales From The Dork Web.