The 6502 processor has a special place in the childhood memories of many of us, because in the 80s it was at the heart of many micro (and not-so-micro) computers. The Apple II is probably the most iconic. But not one of the best, honestly, and for many of us the real winners were Vic-20 and C64: “the” 8-bit home computers, together with ZX Spectrum.

6502 Assembly is a good start if you want to play with bits, bytes and registers. It’s easy enough not to be intimidating, but it’s a real Assembly with actual potential applications. And there’s plenty of online courses to learn it, even if most of them are focused on retrogaming platforms like Atari VCS and Nintendo NES.

It’s also a good way to learn “programming with limitations”, since old systems of the 80s didn’t offer much in terms of digital resources. That said, there’s plenty of room for improving your low-level programming skills. And then jump to more complex platforms.

It could sound a bit esoteric, but there are different ways to emulate a 6502 processor using simple SBC boards - kind of obvious: a modern board controller is more powerful than a 6502 chip. With a good emulator and a good SBC, you can have a little portable retro machine, customized for your own digital tastes and ready to play your own games (why not?).

The current wave of lliputing owes a lot to Arduino boards, bacause they have in some way commoditized microelectrobc development. Of course, a lot has changed since Arduino’s first days and a big chunk of Arduino stuff is, today, even too much powerful and too much "cloudy" (i.e. connected to Arduino cloud) to be really interesting from a permacomputing standpoint.

But you can still buy simpler boards – like Arduino Uno, the (more or less) original one - and start interesting projects on them. In the collapse/frugal computing sense, they’re perfectly viable systems. And if you don’t like the Arduino C-like language, there are other ways. Like MicroLisp or MicroPython.

People usually underestimate collapse computing because the chances of a general collapse are, fortunately, (relatively) low. But this does not matter that much. We already have parts of the world where computing resources are scarce. And the 2020-21 pandemic clearly showed how much our supply chains are fragile.

More generally speaking: low-power, self-contained, easy to assemble/repair/use computing machines are a good thing. Simply, we're not used to see things this way anymore. Consumerism and late stage capitalism turned us into passive consumers of technology, with almost no agency on it.

I've always thought that cyberpunk-style cyberdecks are a good starting point to design a post-collapse computer. They’re self-contained, portable, with an optimized interface. In fact, the cyberdeck concept is so popular that there are many real world versions made by hobbysts. Some are impressive in how they replicate cyberpunk vibe and aesthetics. And most of them are based on SBCs, so they already are (relatively) easy to assemble and repair – if you know what you’re doing.

In general, hardware is not an issue in designing post-collapse computing devices. Most hobbyst boards have enough computing power and can be connected to a wide range of peripherals.

The real fun for me is in their software, because designing a frugal software environment goes against what normal developers do today: writing code assuming you have unlimited resources to manage an unlimited complexity.

Collapse/frugal computing forces you to work with constraints and to develop a software environment that is simple, robust, adaptable, efficient. Any modern OS doesn’t have all this features. And a “collapse machine” shouldn’t even be based on a conventional OS concept, or a GUI.

The most efficient user interface for a collapse/frugal device is first of all a text-based interface (a TUI) with, in perfect Unix style, a collection of programs designed to do a single thing, but doint it well. The step further is, I think, a REPL environment where you can build programs stp by step. Defining your own functions and assembling them in complex sequences. In some ways, REPLs are (also) OSes.

A functional language makes sense, in a collapse device, because it makes problem solving easier. Decompose your problem in steps, turn them into functions, code and test them in the REPL. It’s easier than sitting at your desk – maybe you don’t even have one after the collapse – and writing long code pages in an imperative language you then have to compile and load.

Collapse/frugal computing simplicity leads to native REPL environments: Forth or Lisp. Yes, they’re old languages but that’s a plus, post-collapse: they’ve been engineered to work on basic machines, with basic interfaces and (if needed) no external libraries. Launch the REPL, create your functions/words, assemble your programs.

Lisp and Forth REPLs on single-board computers are nothing new and are not hard to implement. MicroLisp is a Lisp for SBCs available for many platforms and I’ve directly tested it on a very basic Arduino Uno board (one of my pet projects is to create a whole system around that implementation, we’ll see…).

Digital surveillance is on the rise everywhere and it's a risk we all should consider. Unfortunately, there is no way to be connected and, at the same time, to be completely safe. Mix this with my other big interest - collapse computing - and the result is the concept of unpermanently connected computing and memory devices, which can join the Internet as usual but also, better, use other means of communications. And store locally important chunks of information, from personal data to common knowledge.

The idea of a portable, (dis)connected, low-power memory/computing device is very old and I'm not inventing anything here. Mine is just another concept. That reminded me the Voyager missions, admirable for their use of scarce computing/storage power, reliability, stubborness in working years after their supposed end of life (and some snafu). So: Project Voyager.

First step: impelementing the "Voyager model" with a standard notebook PC. This is the easiest trick - almost trivial, you can say - but it's also the best way to understand properly what's to be included (hardware, software, peripeherals, data, applications, scripts) and what not, because it's simply a nice-to-have, or impossible to get, or simply useless.