The story
In the early 2000s humanity discovered the Field — an impossible technology, understood
only well enough to use. A few years later came worse news: an extinction event Earth could not
survive.
There was room to save only a fraction — a few hundred million, chosen largely by lottery. The
evacuation fleet scattered on deliberately different courses, each ship a civilization seed
carrying the means to begin again, its passengers asleep in Field suspension.
Then Field transit went catastrophically wrong. An interval passed that no one can measure — the
surviving records disagree, and the true figure is not something the living can know. They call it
The Dream. The sleepers woke far downstream of their own history, into an old, cooling cosmos
where the last long-lived stars are burning down.
Only a handful of Earth's ships are known to have reached this region. Local civilization has
stood here for some twelve centuries. Thousands of the Earth-born are still under — Dreamers;
those who wake are the Awakened; those born since, Naturals. Earth is at once
unimaginably ancient and living memory.
You are newly Awakened. The ship is yours to understand.
Devlog
15
BCH is frozen — and it's yours to play
The prototype set out to answer one question: can 0•X make a ship feel like a real,
understandable machine, with a genuinely programmable computer at its heart? It can — so
we're drawing a line. BCH ("Beyond Current Horizon") is now frozen: the computing
stack, the ship simulation, and the diagnostic loop are proven and sealed behind a tag, and the
build is out the door.
It's a free download. You power on a cold ship, boot its computer, and work it — read the
gauges, type Forth at the terminal, trip a failure, and fix it two ways. A full AeturnisOS / A16
manual is bundled. There's no flight or story yet; this build exists to prove the machinery,
and it does.
▸ Play the prototype — free
Next, the work gets a name of its own: Earendel — which gives this machinery mass,
motion, and a universe. BCH proved the ship is a machine; Earendel makes it fly.
14
Make it break — then fix it, two ways
The prototype now does the thing it was built to prove: a complete diagnostic loop. A small
test harness injects a real component fault — a failed coolant pump, a lost dock umbilical,
a thruster stuck firing, a slow cabin leak — and then gets out of the way. Nothing downstream is
scripted: a failed pump means no coolant flow, so the loop heats up, so the gauge needle climbs and
the controller raises an alarm — exactly as it would for a genuine failure. The scenario is
artificial; the failure is not.
You diagnose it however you like — read the analog gauges, or ask the computer at three
depths: a one-word whole-ship dashboard, a per-subsystem detail, or your own monitoring loop
written in Forth. Then you fix it — and here's the point: every fault is solvable two genuinely
different ways. One from the terminal (type an operator command: shed load, bring the standby
pump online, isolate the thruster, reconnect shore power) and one physical — flip a breaker
or a switch on the engineering board, or dog a hatch. The command and the switch drive the
same control underneath, so neither is the "intended" answer.
The engineering board — breakers plus a backup-pump and thruster-isolate switch. Each physical control does the same thing as a word you can type at the terminal.
Some fixes are containment, not repair. A cabin leak can't be patched from the cockpit — but
you can seal the cockpit off: dog the hatch, and the cabin gauge keeps falling while the cockpit
gauge holds. And when you want to run it again, a dock-side console resets the ship — one
grade restores it to nominal and keeps your work; another power-cycles the whole computer and
recovers it even if the terminal has crashed.
Open a leak, then dog the hatch: the cabin gauge keeps venting into the red while the sealed cockpit holds — containment, made visible.
13
The ship, in three dimensions
The ship used to be one placeholder room. Now it's a real four-compartment utility craft —
cockpit, habitat, engineering, airlock — that you fly through, assembled from a modular kit
and built from the same validated blueprint the physics simulation runs. There's one
source of truth: change a compartment in the data and both the simulation and the 3D ship change
with it.
Two things make the engineering loop physical. Analog gauges read the simulation's
actual physics directly — so a faulted sensor and the needle can disagree: the computer
reports a lie while the dial stays honest. And external cameras (bow, aft, and a hull-mounted
docking cam aimed at the berth ring) feed a bank of cockpit monitors, deliberately low-fidelity —
late-90s security-camera monochrome. And it all floats against a sparse, dim starfield —
deep space, not a bright planetarium.
Fly the four-compartment SV-1: live gauges that can out-truth the computer, CCTV viewscreens, and a terminal running AeturnisOS.
And the terminal isn't set dressing — it's a real computer. Below, a whole maze game is
written in Forth at the ship's console: defined word by word, compiled, then played with
the keyboard — running live on the Aeturnis A16.
A maze game coded in Forth at the terminal, then played — walls, coins, score, all running on the A16.
12Our own CPU: the Aeturnis A16
The ship now runs on a processor we designed. The prototype's DCPU-16 was the starting point;
the Aeturnis A16 is a clean break — status flags and conditional branches instead of
skip-if, two hardware stacks, auto-increment addressing, and first-class
interrupts and faults. We wrote its emulator and taught our assembler to speak it, froze
the instruction set as a spec, then did the real test: port the whole OS to it.
The port is what proves a CPU. AeturnisOS came out smaller and cleaner exactly
where the design promised: the Forth inner loop halved, the register juggling vanished, and two
things became real that the old chip couldn't do — the keyboard is interrupt-driven (the
CPU sleeps until you press a key instead of spinning), and the machine monitor gained
real breakpoints (a BRK traps into the debugger; a divide-by-zero now lands
there too instead of corrupting). Same Forth, same display — new silicon underneath.
The A16 boots AeturnisOS on the CRT; walk up and define a word: : SQUARE DUP * ; then 5 SQUARE . → 25.
11Our own computer: AeturnisOS boots
The monitor no longer runs the prototype's software — it runs AeturnisOS, written from
scratch. We built a DCPU-16 assembler, then an OS on top of it: a diegetic
power-on self test, a machine monitor for poking memory, and a real
Forth — the command line is the language. You can define words and run them:
: SQUARE DUP * ; then 5 SQUARE . prints 25. The machine
extends itself.
The screen is ours too: a new 8×12 text display controller (ATDC/1) with an original,
hand-drawn font — legible enough to read code on. With that, the last piece of the prototype's
software leaves the ship, and Phase 0 is complete: the whole computing stack — assembler,
OS, Forth, display, font — is independently authored.
Walk up to the terminal; AeturnisOS has booted; type a Forth definition and run it.
10Milestone 2: the look — before & after
Milestone 2 is done: the room now reads as a lit spacecraft interior. The monitor runs a
CRT shader (soft phosphor pixels, glow, anti-aliased scanlines), the room is lit by
authentic 2002/ISS-era fluorescents (cool-white with a faint green), glossy surfaces
pick up environment reflections, lights cast soft shadows, and a glass front
glares on the CRT at grazing angles. It holds a vsync-capped 60 fps.
Below is the exact same camera move as the Milestone 1 clip — same path, same keystrokes —
so the only thing that changed is the look.
Same shot, before (M1) and after (M2): fluorescent tint, scanlines, glass glare, soft shadow.
09Milestone 1: you're in the room
Interactive parity is done. You spawn in the cargo bay, walk with WASD and look with the
mouse (Pilot mode), and press Tab to sit at the terminal (Terminal mode)
and type into the DCPU. Floating at the centre is the prototype's spinning test cube — no
meaning, just Notch's renderer test prop, reproduced faithfully (and a handy lighting target
for what's next). It's not pretty yet; that's Milestone 2.
Milestone 1 in motion — walk in, cube tumbling, then type at the terminal.
08You can type into it now (M1.1)
Wired keystrokes into the DCPU's keyboard ring buffer (0x9000), so the Ready.
prompt is live — type, Enter, Backspace. The DCPU side was proven by tests immediately; the
screen just wouldn't update, which turned out to be a Bevy gotcha: the live texture re-uploads
but the material's bind group was stale, freezing the display on the first frame. Touching the
material each frame fixed it.
First words on Aeturnis hardware.
07Scale is a pillar now — measured before greenlit
Hard sci-fi needs believable proportions, so scale is an enforced invariant: 1 unit = 1 m,
and canonical assets must pass a hard gate against a ship-ergonomics canon (deck
≥ 2.1 m, hatches ≥ 0.8 × 2.0 m with a knee-knocker sill, …) before they build. The
prototype stays faithfully loose on its own layer. Every QA render now drops a 1.80 m human
in for context.
A 1.80 m figure in quarters_a (2.4 m deck) — scale you can read at a glance.
06Making the banner ours
The DCPU's Copyright 1985 Mojang is a fictional in-joke (ancient retro tech),
so the boot banner should stay fictional — just not Mojang's. Wrote a project-owned boot
ROM (roms/src/os.asm) with our own in-universe maker and a retro copyright
(2002, the lore's sleep-cell year +14). Notch's original ROM stays as the CPU test fixture.
Aeturnis Development Labs LLC · (C) 2002.
05The screen is on the monitor
Wired up a Bevy app that boots the DCPU and renders its live screen RAM through the
pipeline's font + palette onto a 3D monitor in the cargo-bay room. Running on the GPU
(RTX 2070 / Vulkan). Everything finally meets in one picture.
DCPU BASIC 1.0 glowing on a CRT in the cargo bay.
04Rooms from an algorithm, not a mesh
Built the asset pipeline: declarative specs → headless Blender → glTF. The room generator
is a straight port of Notch's renderRoom() — a box with 0.2-thick walls and a
doorway. The font and 16-colour palette are extracted from the recovered 2012 source, so
the look is byte-faithful.
cargo_bay.glb, generated and rendered headless.
The authentic 4×8 font, round-tripped from font.png to font.rom.
03A faithful DCPU-16, and it boots his OS
Ported the prototype's DCPU-16 to Rust (#![no_std], faithful v1.1). The headline
test boots Notch's own os.asm — assembled by his original assembler — and asserts
the banner lands in screen RAM. It immediately caught a real bug: an off-by-one in conditional
skip. Nothing validates an emulator like running real software.
02The prototype turned up
Recovered Notch's original 2012 Java/LWJGL prototype, decompiled it, and mapped it out: the
v1.1 DCPU, the memory-mapped screen at 0x8000, the real font, the genColor
palette — and an earlier auto-generated 6502 emulator he built first. Primary-source gold.
01Research & the name
Compiled a cited spec/reference for the whole game and settled an early identity —
0x101a, a +14-year reframe of 0x10c (exponent tracking the year, 2012→2026). Since
renamed 0•X; the length of the sleep is now canonically unmeasured — "The Dream."
