Back to blog index

Salvage computing

Now playing: "It's Real" by Real Estate

I'm working on a new project to turn e-waste into usable personal computers. I have no idea if it'll get off the ground, but I think the collection of ideas is cool and worth sharing.

The core concept of the project is *salvage computing*. I first learned about the idea from doing research into permacomputing [1], a topic I'm very passionate about. Salvage computing is largely about using e-waste and other junk electronics to create new devices, instead of buying new components. Not only is this a very sustainable way to create new devices - most of the energy consumed by a computer is used during its creation, not its operation [2] - but it also provides resilience against supply chain issues. The electronics industry has a very global and very fragile supply chain, so being able to use existing hardware for as long as possible gives local options when international ones fall through.

I live in a fairly large and diverse urban area, so there's lots of e-waste to be found. Most of the "PC-like" hardware - desktops, laptops, mini PCs - get saved from landfills and refurbished by the crowd of repair shops in the area, but a lot of the e-waste that I see getting thrown away is non-PC elcetronics. Many of the old routers, DVD players, and other microprocessor-based tech I've found at thrift stores and on Craigslist go underappreciated and never get bought.

That gave me the idea - why not try to use microprocessor-based systems like that as a PC?


Of course, microprocessors are distinct from regular computer CPUs for a reason. There are definitely ways to run "normal" OSes and programs on microcontrollers (OpenWRT [3], etc.), but it isn't as simple as plugging in a USB drive and installing a new OS. Many embedded systems aren't deisgned to allow running arbitrary firmware, so writing and installing custom firmware is often complex. Additionally, microprocessor designs vary wildly from one another and typically include weaker CPUs and less RAM than typical CPUs.

I know that whatever software and firmware I develop for these "scrap computers" will need to account for a pretty low baseline of hardware:

I've decided to handle work around many of these issues by basing my systems on Uxn. Created by the 100 Rabbits art collective, Uxn is a virtual machine standard designed to be intentionally limited and simple to implement on a variety of systems - exactly what I need. [5] Uxn also has the benefit of being fairly easy to understand at a fundamental level, which I hope will give future users of my scrap computers a path to understand and operate their devices better.

I plan to implement the underlying Uxn VM in C so that it can be easily be ported to a diverse range of platforms. Almost every processor architecture and individual microcontroller has some kind of C support, so this will save a lot of effort in the long run. This does run into a bit of an issue with the concept of bootstrapping [6] - how can a user modify and flash C-based firmware from inside a Uxn-based VM? For this, I want to try embedding the Tiny C Compiler, or TCC, directly into the VM's code as a system device. [7] This isn't the best solution, but it should be workable.

Another key issue with using Uxn as a foundation is that Uxn doesn't provide any networking tools. The Varavara specification for device support in Uxn doesn't include a way to access networking hardware [8]. However, it *does* offer two "reserved" device slots for non-standard Uxn VMs to add custom devices, as well as two additional slots that are seemingly-unused in the specification. Thus, I can expose a TCP/IP "device" in my Uxn VM that wraps TCP and TLS connections nicely using mbedTLS or a similar library. [9] This should also allow future apps written in Uxntal, Uxn's base "assembly" language, to implement IRC, Gemini, and other web protocols without dealing with the intricacies of implementing public-key encryption and a full TCP/IP stack in a slow 16-bit VM, as interesting as that would be.


The first device I plan on using for my scrap computing endeavors is an old WiFi router I found in the Goodwill clearance bins. I was lucky enough to find a Linksys WRT54GS (?), which actually features in a number of custom firmware and software "hacking" projets in the 2000s and 2010s.

This particular router doesn't support any fancy peripherals like USB ports. It has a 32-bit MIPS microprocessor, a standard Wi-Fi transciever, a 5-port Ethernet switch, and a bunch of LEDs on the front that are driven by the processor's GPIO pins. That being said, it should be possible to:

This would almost get me a usable desktop device! The only extra peripheral I would need to add support for is a display, which I have a couple of ideas on how to do.

I have a miniature (2.8" diagonal) touchscreen display from Adafruit, which I bought years ago for a projcet but never ended up using. [13] This display connects over SPI, so I can connect it to the microprocessor using the same wiring bus as the SD card. Adafruit also publishes a well-documented C library for using this display, so it would be an easy solution in software too. It's a small screen for a desktop device though, and it wouldn't give me many options for connecting other, larger displays in the future.

My other option would be to fashion a display connector and driver out of the tech that I already have. I have an unused Raspberry Pi Pico, which offers several programmable I/O (PIO) pins for generating very precise control signals - like for generating video signals for a display, for example. Several folks online have already implemented working VGA display output on the Pico's PIO system; [14] if I can do the same, then I can take advantage of the plethora of VGA monitors that get thrown away every year. The Pico could then connect to the router via SPI, like my mini touchscreen display.

In either case, I should be able to make a usable desktop out of the router, complete with a display and a USB keyboard and mouse.


I don't expect these scrap computers to be the best option for the average person. Folks won't be able to browse social media, or play (most) video games, or check their bank account balances. What they *could* do, though, is write and read, and converse slowly and thoughtfully through blogs and forums, and make art and music, and create spreadsheets, and do many of the other things that I see people wanting to use their devices for that don't involve the attention economy. I'm not sure whether that will be enough to get non-techy folks interested in salvage computing, but I have hope.


[4]: I want to utilize devices that can be made to support web browsing, chat, and other Internet-based use cases as much as possible. I want this project to produce devices that people *want* to use daily - myself included - so a secure Internet connection is a priority. To that end, mbedTLS and other cryptography libraries require 32-bit or larger processors.


Published .