uxn design

As it stands today, modern software is built with extreme short-sightedness, designed to be run on disposable electronics and near impossible to maintain. We decided to not participate. Our aim is to create a machine that focuses on answering the handful of little tasks we need, which is centered around building playful audio/visual experiences.

Uxn was created explicitly to host software on pre-existing platforms, the design was advised primarily by relative software complexity, not by how fast it could run on new hardware standards. Features were weighted against the relative difficulty they would add for programmers implementing their own emulators.

Stack-machines are ideal candidates for this scale of personal computing. Not only do they limit the complexity of the assembler, the resulting programs are succinct and translate well to pen & paper computing.

With only 64kb of memory, it will never run Chrome, TensorFlow or a blockchain. It sucks at doing most modern computing, but it’s also sort of the point, it's more about finding what new things could be made in such a small system.

While terminal utilities can be made portable, cross-platform graphical development is different. Even building projects for platforms with C compilers, such as Linux and Plan 9, will require a near total rewrite, whereas porting the thin layer that is the uxn emulator will allow that same rom file to be used on both systems.

Why create a smol virtual computer?

We want to produce lasting versions of our tools and games, and by using simpler systems(the UxnVM is about 100 lines of C89) we can begin to experiment with designing projects that could still be played in many years.

To borrow the words of Viznut Heikkilä on permacomputing, we're interested in cultural and ecological permanence. "That is, how to give computers a meaningful and sustainable place in a human civilization that has a meaningful and sustainable place in the planetary biosphere".

story

Back in 2016, when first operating on a sailboat, we experienced frequent failures with both software & hardware, largely due to our small energy storage and lack of reliable connectivity. The solution was to create tools that would be better suited to the limits of our new situation. The objective was to replace the bloated subscription software that we were using to do creative work, such as Photoshop, Xcode and Ableton. We were somewhat familiar with web technologies, so we decided to build our programs on this new up and coming framework called Electron.

While solving some of our issues, Electron was rapidly increasing in size and hunger, so despite it being open-source soon joined the rest of the software that we did away with. Our focus shifted toward reducing our energy use, and to ensure reliability we began removing dependencies.

To transition toward our new goals, we developed offline web versions as temporary stand-ins while researching ways to build more resilient software. We eventually ported our tools to C, but while we had achieved ideal energy usage, portability was still an issue for graphical applications, so we kept looking. We learned 6502 Assembly, seeing players run our games as NES roms on all these different platforms gave us an idea.

In 2021, we began designing a small virtual machine with a focus on implementability; meaning that moving forward, the applications themselves would no longer need to be ported. Instead, to make any one program available on a new platform, the emulator would be the only code needing to be modified, which is explicitly designed to be easily implemented.

This is where we are now. Uxn might solve our cross-platform issues, while being quite light and energy efficient. We hope that one day the Uxn versions of our software replace the desktop and web versions — But, we'll have to see about that [16.05.21].