The Mechatendo
After the apocalypse, how will you get your solitary interactive entertainment? With a mechanical computer of course!
As a bonus, it’s also great at helping you practice mindfulness (i.e. patience).
The machine I envision in my head implements a simplified version of Brainfuck. It’s a 16-bit system in that there’s a whole 16 bits of memory. The program is encoded on a paper tape punched out with the instructions. The tape can also have text and images printed on it, which are skipped over. As for the user interface, there’s a viewport that lets you see a portion of the tape. The machine runs until it reaches a halt symbol, at which point the machine stops, the viewport showing the output. It resumes when the user inputs a 1 or 0.
With a system like this, you can implement a very simple and slow RPG complete with illustrations. Or I guess you could do some math. Rest assured though that this device is designed to discourage productive use.
Semantics
Memory is 16 bits and wraps around when rotated. Initial data is arbitrary. The program tape can be as long as you want.
Symbols:*
No-op.
Halt. When resumed, the current bit is replaced with the user’s input>
Rotate memory 1 bit to the right<
Rotate memory 1 bit to the left0
Write 0 to the current bit1
Write 1 to the current bit[
If the current bit is 0, jump forward to the symbol after the matching ]
symbol]
If the current bit is 1, jump backward to the symbol after the matching[
symbol
After executing a symbol, the program read head advances to the next symbol.
[
and ]
nest. For example, the first [
in the program[[]]
only matches with the last ]
. The maximum nest depth is 16 and
exceeding it is undefined behavior.
Jumping when the current bit is uninitialized is undefined behavior.
Reading past the beginning or end of the program is undefined behavior.
In the simulator, undefined behavior shows an error and aborts the program.
The program tape viewport begins 20 symbols past the program read head and is 20 symbols long.
Note that in the physical machine, the user would typically start the program on the blank portion of the tape before the actual program, running no-ops until the program is reached. Due to this, a program should typically start with a halt to indicate to the user that it is ready for input.
The Physical Thing
While I utterly lack the handy-know-how to craft such a wonder, I do possess the magic of imagination in which I have confirmed through (thought) experimentation that it definitely works.
The basic machine is probably a set of camshafts that are somehow selectively enabled and disabled. For each rotation, the following happens:
- At the symbol read head, something pokes through the holes in the tape, activating really cool gadgetry that activate and deactivate various parts of the machine
- The camshafts do their thing in their new configuration, performing the symbol's instruction
- The program tape is moved to the next symbol
I imagine the memory as a wheel with maybe switchable levers on it? Whatever's convenient to read and write mechanically, really. The wheel idea seems simple and allows the memory to naturally wrap around. Since the memory is left in an arbitrary state after program execution and resetting it manually would be a hassle, programs must initialize their own memory.
The program tape is standard 1-inch 8-data-hole paper tape commonly used by teleprinters. Tapes are punched out one column per instruction and are encoded in a fashion where each instruction gets its own bit. Since this encoding leaves plenty of invalid possibilities, incorrectly punched tapes might cause the machine to physically crash into itself. The tape is read left to right with the 3-bit side on top. Folding is probably the easiest way to manage long tapes.
Jumping is a special state the machine can be in. Instead of executing symbols, it's looking for the matching opposite symbol to the one that started the jump. There would be a gear that counts the nesting depth for jump symbols. This means that there's a physical limit to how far nested jump symbols can be. If the nesting limit is exceeded, I think the machine would erroneously end the jump before the matching symbol is found. Realistically though, I think it'd be trivial to make the counting gear large enough to accommodate any reasonable program. Or, a digital mechanical counter could be used instead.
The machine is powered either through water or weights, because that would be neat. Electric motors went out of style after the apocalypse. A pump for the water might be permissible so long as it doesn't drown out the sounds of clacky mechanisms (important for debugging). Don't let the water get near the program tape.
Text Syntax
For now we're stuck with software simulation, so here's a syntax for a text representation of program tapes.
- Text is encoded as UTF-8
- Symbols as described in Semantics are read left to right, top to bottom
- Whitespace is ignored
- Content between
{*
and*}
indicates a no-op as well as physically printing the contained HTML onto the program tape (whitespace is trimmed). Following*
no-ops will extend the content area. - Content between
<style>
and</style>
indicates a style sheet to add to the head of the program tape’s HTML document. #
indicates a comment. It’s ignored along with the rest of the line
Simulator
ops
Examples
1 | ## Hello World! ## |
1 | ## 6-bit Calculator ## |