The Uxn development diary.
Below are the disjointed thoughts on the creation of a clean-slate computing stack based on a minimal virtual machine.
- Part 1: A virtual machine
- Part 2: A personal computer
- Part 3: An operating system
Before we begin,
Emulation is the reproduction of the actions of a different computer with software, meaning that programs can be made to behave like circuitry. Given that an emulator can translate the actions of one computer onto the other, the same program could be used on both. This is emulation.
Someone could devise the actions of a fictional computer that is not necessarily based on existing hardware, write software for this fantastical computer, implement an emulators for it, and use the same program on any supported computer. This is a virtual machine.
Over the years, I wrote software for various frameworks and peripherals. Most have died with their respective platform, the rest have fallen behind their ever-changing toolchain. Bitrot is the inability to access digital data because hardware and software no longer exist to read its format. Perhaps it's a matter of time until people build emulators to make these projects usable again, otherwise these projects were never truly mine, and my learning of these languages truly only ever belonged to the platforms.
So, why not C? While terminal utilities can be made portable, cross-platform graphical development is not.
I. As Few Bits As Possible
During my research into portability, I kept thinking about how pleasant it was to play NES games today. Pulling on that thread lead me to projects designed explicitly for virtual machines(such as Another World or Quake), which are equally easy to play today, due to their targeting of portable virtual machines, instead of ever-changing physical hardware.
For a time, I thought I should probably be building software for the NES, as to ensure their survival over the influx of disposable modern platforms — So, I did. Sadly, most of the software that I care to write and use require slightly more than a 8-button controller.
II. Tarpits & Houses Of Cards
If the focus of this experiment is to ensure the survival of a piece of code by writing new emulation software for each platform, the specs should be painless to implement. Let's use the time one would need to write a passable emulator as a limit in complexity for this system. Could a computer science student implement a mediocre emulation of the 6502 instructions in an afternoon? Could that design be simplified, changed in some way to make it more approachable for would-be implementers?
Subleq is a One-Instruction architecture, an emulator for this platform takes at most 15 minutes to write. Perhaps this could be an interesting target, but what it does away in emulation complexity, it offloads onto the toolchain that will turn the text into programs.
Okay, let us also set a limit to the complexity of the toolchain as to not find ourselves in a tarpit. How complex can an assembler be if the maximum amount of time one could use to write it is a single afternoon. It would be an equally herculean task to build an emulator and assembler for a machine with thousands of instructions; or a single instruction subleq that builds abstract logic from thousands of its primitive parts.
III. Things Betwixt
A paper computer was created in the early 1980s, when computer access was not yet widespread, it consists of a piece of paper with 21 lines of code on the left and eight registers on the right. The instruction set of five commands(inc, dec, jmp, isz, stp) is small but Turing complete, meaning that it can approximately simulate the computational aspects of any other real-world general-purpose computer, and therefore enough to represent all mathematical functions.
In 1977, a programmer wrote a small virtual machine with 36 instructions, 16 registers and 4096 bytes of memory. It has no mouse, the screen is barely capable of displaying readable text, the keyboard is a nightmare — But I was able to write an emulator and an assembler for it, in an afternoon.
There is a type of electronics relevant to emulation that has no chips, no instruction set, but instead the programmer designs the hardware circuit in software. As much fun as it would be to create a design that maps well onto these machines, it would make for a poor emulation on my existing devices as it would use nearly none of the optimizations available on the host computer.
Somewhere along this voyage into finding a suitable host for my programs, I began thinking about electronic waste, and I couldn't justify surrounding myself with yet more electronics. This dream platform would therefore be designed to be emulated, its complexity would be designed around the complexity of software and not that of hardware.
IV. Back & Forth
The balancing act of virtual machine instructions, assembler, emulator and the resulting capabilities of its language revealed the stack machines as ideal systems.
Forth is a programming language that consists simply of splitting text into a list of words, breaking on whitespace, and to interpret each word, words are often combinations of other words combined to create more complex words.
Brackets and parentheses are unnecessary: the program merely performs calculations in the order that is required, letting the automatic stack store intermediate results on the fly for later use. Likewise, there is no requirement for the precedence rules.
In Forth, memory is made of cells, which are typically 16-bits in length, meaning that each piece of data is a number from 0 to 65535. For this specific imaginary system, I wanted the memory to consist of cells of 8-bit, or numbers from 0 to 255. For example, the
12 / (34 - 12) sequence is equivalent to 6 bytes:
uxn | #12 #34 OVR SUB DIV binary | a0 12 34 06 19 1b
V. Where To
As opposed to the seemingly natural trend in software, Uxn is reaching backward in time and making itself available further and further back in time(1987), growing increasingly smaller(1kb). I keep on circling back to paper computers, and how much I want a machine such that even if people took computers away from me, a piece of paper could serve as a viable host in its stead.
This is all for now, the next devlog will cover the creation a personal computer hosted on this virtual machine. Thank you for reading.
The realization of this project is largely due to the work of the community, with special thanks to Andy Alderwick, Sigrid, and everyone else who contributed ideas and shared their knowledge with me, without whom Uxn could not have become what it is now. Nearly a year after its initial draft, a lot of uxn code has been written. In fact, this text has been written in Left, a text-editor hosted on this strangely personal computer, oh, and this entire wiki was also built by it.