Collapse OS — Roadmap

Before we start

Have you read the Winter is coming page? It's important to read it in order to make sense of this project. Otherwise, it might look like total insanity.

General goals

Minimal systems? There's tons of them. Self-assembling systems? There's tons of them. Running on less than 10K transistors? not so much.

If we assume that lower complexity will be forced upon us, we need such a system, a system that is capable of running and self-replicating on very low transistor count.

Collapse OS has no target machine because those machines it's going to run on don't exist yet and will very often be cobbled up together. However, it has target specs, inspired by Grant Searle's minimal z80 computer: it should run and self-replicate on 8K of ROM and 56K of RAM.

Anything bigger starts being much more complex because you need memory paging, and if you need paging, then you need a kernel that helps you manage that, etc.. Of course, I don't mean that these more complex computers can't be built post-collapse, but that if we don't have a low-enough bar, we reduce the likeliness for a given community to bootstrap itself using Collapse OS.

Of course, with this kind of specs, a C compiler is out of the question. (Ok, ok, not impossible, but impractical and inefficient) Even full-fledged assembler is beginning to stretch the machine's ressources. The assembler having to be written in assembler (to be self-replicating), we need to design a watered-down version of our modern full-fledged assembler languages.

But with assemblers, a text editor and a way to write data to flash, you have enough to steadily improve your technological situation, build more sophisticated machines from more sophisticated scavenged parts and, who knows, in a couple of decades, build a new IC fab (or bring an old one back to life).

Outwards, inwards, sideways

For this project to be a success, it needs to be solid, very well documented, focused. Software projects have a tendency to suffer from feature creep, that is, to have an imbalance between "outwards" development (new features) and "inwards" development (consolidation).

It requires a lot of discipline to do proper consolidation. Generally, outwards development uncovers new possibilities and the mind gets excited with these, making the development endlessly postpone consolidation.

This is why I'm trying to clearly define when the outwards phase stops, when we can consider the project finished. Then comes the consolidation phase, which is mostly writing documentation and recipes.

I also add "sideways" development on the roadmap to leave the door opened to further improvements. It's easy to imagine adding assemblers for new MCUs or adding support for new peripherals could enhance the project greatly without adding significant complexity. It would then be a bit short-sighted to prevent that kind of development. Provided that it doesn't hampers the "inwards" process, I imagine this kind of development possible.

Goals

The roadmap for the "outwards" phase to be considered complete is already outlined in the home page. Below, I expand on those broad goals with more specific sub-goals, striking those that are considered done.

  1. Run on minimal and improvised machines.
  2. Interface through improvised means (serial, keyboard, display).
  3. Edit text files.
  4. Compile assembler source files for a wide range of MCUs and CPUs.
  5. Read and write from a wide range of storage devices.
  6. Replicate itself.

Non-goals

It's worth mentionning, however, that supporting specific peripherals isn't on the roadmap. There's too many of them out there and most peripheral post-collapse will be cobbled-up together anyway. Peripherals listed in the goals section above are just one of a kind.

The goal is to give good starting point for as many types of peripherals possible. We expect the post-collapse user to adapt existing code to specific hardware in inventory.

It's also important to keep in mind that the goal of this OS is to program microcontrollers, so the type of peripherals it needs to support is limited to whatever is needed to interact with storage, serial links, display and receive text, do bit banging.

Participate in the project

Let's face it, among the niche projects out there, this is really, really niche.

I don't think that there are many people out there with both the inclination and the skills to work on this. However, z80 assembly is a skill that can be picked up pretty quick. I went from "never heard of z80" to "self assembling z80 assembler" in less than 3 months.

Without a bit of an electronics background, however, I don't see how someone could use or improve Collapse OS, so that's kind of a hard requirement. Personally, I have a software training but I've been an electronic hobbyist for 2 years, so I've had time to gather important know-how which is essential when trying to use Collapse OS.

I expect that as global events unfold, interest in this project will grow. When that happens, I don't expect that we'll have much time left before blackout. At this point, the project will have to be ready for dissemination before blackout. There won't be much time for further improvements in a global context.

All of this to say: if you have the inclination to participate but don't feel like you have the skills, please consider ramping up your skills. It could make a big difference. If you can manage to run Collapse OS on any real hardware, you're very much qualified because this is hard! (ok, the Genesis+Everdrive+D-pad combo is actually easy. Let's say that if you manage to also build a PS/2 adapter for it, you're qualified)

"Do you have tips for how I could ramp up my skills?", you might ask. I'm glad you asked! As a matter of fact, I do!

I can be contacted at hsoft@hardcoded.net. My name is Virgil Dupras.