Introducing ATTARC: Advanced Transport Triggered Architecture for Redstone Computing

One day I got bored of playing Minecraft survival, and I decided to build a redstone computer.

ATTARC 1.0

Given my background as a computer engineer and the many helpful Redstoners in the community, this seemed like a fairly achievable goal. Still, I had never previously designed a CPU from scratch; I'm old-school but not quite that old. But I was confident that I had the requisite knowledge and experience, so I began the design process.

I started by asking myself this question: "What does a computer fundamentally DO?"

The answer in my head: "It shuffles bits around".

So I decided I could just build a bus, some registers, attach some peripherals, decoders, a program counter, and some ROM, and it would be a brilliantly simple but powerful and flexible computer.

Then I thought to myself, "Somebody else must have already thought of this."

Sure enough, somebody had, and it even had it's own wikipedia page: https://en.wikipedia.org/wiki/Transport_triggered_architecture

So no patent royalties for me, unfortunately. But on the upside I knew my concept was sound.

TTA is basically RISC reduced to only one-instruction: "MOVE". This copies a value from one register to another. Other operations happen as side effects; IE when you move numbers to the adder input registers it triggers the addition and the result shows up (eventually) in the output register.

So every instruction is basically 

MOVE src dst

More complex instructions are implemented as assembler macros, essentially.

The main upshot is that TTA assembly is essentially vertical microcode; just like in the Pentium Pro any many other historical CPUs. If you slap a decoder and sequencer on a TTA CPU you basically get a "normal" CPU.

TTA has many advantages of interest to the redstone computing community. In particular, in it's minimal form, it is just about the simplest possible way to build a useful CPU. At the same time it can be scaled up to powerful parallel superscalar designs to match the fastest CISC and RISC CPUs. It's very easy to customize TTA designs and scale them up or down. Because of the extreme simplicity of the single generic MOVE instruction it's relatively easy to assemble code written for other platforms; eventually I would like to support the PIC16 ISA although I'm also thinking about  the Z80 or x86 or 6502.

There are a few downsides.

Code density is low. This makes it challenging to build a large ROM. There are many ways to ameliorate this, like data compression. This would work in minecraft, but would increase the pipeline depth.

Simple addition requires at least three instruction cycles, two to set up the inputs and one to read the result. This is offset somewhat by the high speed of instruction execution; like RISC, and unlike CISC, TTA completes one instruction every clock cycle. It's also offset somewhat by the slow speed of Minecraft Redstone adders.

Compiler complexity varies from high to very high. In a TTA the compiler is responsible for many details which are handled automatically by hardware in other architectures. Even the assembler is responsible for implementing the "real instruction set" as a bunch of MOVE operations. Advanced TTA's can have complex inter-instruction timing dependencies that somebody has to pay attention to, either the programmer, assembler, or compiler.

I began to come up with some general goals

1. Fast: I play on bedrock so no MCHPRS for me. I was hoping to achieve 10hz performance, or something close to it. None of this 20 or 30 ticks per cycle business.sasa
2. Small: which is implied by fast, but not so small that speed is sacrificed.
3. Cheap: I wanted to design a computer that could be built in survival.
4. Simple: I'm a smart guy but this stuff is still time consuming and my MVP is a working 8 bit computer, not an Itanium. Besides, complex circuits are slow. And I want the community to be able to take this design and run with it.
5. Focus on CPU architecture; plenty of great designs already for RAM, ROM, ALU, displays, etc. I'm a computer expert, not a redstone expert.
6. Asynchronous; redstone is already clocked at 10hz so as all the timings are synchronized, it should not be necessary to have a global clock, it should be enough to just put addresses on the bus.

First I hit the books. I spent a lot of time reading the datasheet for the Maxim MAX-Q, the only commercially available TTA microcontroller. https://www.analog.com/en/resources/technical-articles/introduction-to-the-maxq-architecture.html

I also spent a lot of time reading about very old and slow computers from the ancient past. I figured whatever they did back then to make those clunkers go would be applicable in slow-as-molasses Minecraft as well. I learned an awful lot about the history of CPU design.

I started with the bus design. Given redstone's abysmal 1 tick per 16-ish block latency, it was critical to keep the bus as small as possible. After several experiments I came up with is an H-shaped bus spanning four chunks with only two redstone ticks of delay. This delay is constant across the whole bus so every instruction takes a constant amount of time. Four chunks is plenty of room for whatever peripherals you want to include and provides an excellent starting point for customized designs.

I designed the ROM, program counter, GP registers, and barrel shifter from scratch. Unfortunately I wasn't smart enough to independently develop the cancel-carry-adder, although I came close. I ended up using MattBattwing's design. For RAM I chose TheDarkness344's design. I got the RNG from the Minecraft Wiki. I also added inverter and "is-zero" peripherals.

Add about a year of building and testing and VOILA! The Advanced Transport Triggered Architecture for Redstone Computer (ATTARC) has come into being.

It's basically finished, and I'm running test programs, although I haven't fully qualified all the parts.

My primary test program calculates the Fibonacci sequence up to 16 bits including overflow detection and halting. This demonstrates addition and conditional jump functionality, proving Turing-completeness. It's a "real computer" for all you haters out there, even if it doesn't have a screen yet.

16-bit Fibonacci sequence output

Eventually I hope to expand the memory enough for it to support self-hosted development in BASIC or FORTH or something. My goal is 4KB each of RAM and ROM.

I also want to estimate Pi.

ATTARC 1.0 Specifications

• 2.5Hz/4-tick instruction cycle speed
• Scalar design, executes exactly one MOVE instruction per cycle
• 8-bit data bus
• 5-bit address busses
• 256 15-bit instruction word ROM
• 256 8-bit words of dual-ported RAM
• Indirect addressing
• Auto-incrementing RAM address registers, stride by powers of 2
• 8 high speed general purpose registers
• 8-cycle branch delay
• Branch delay instruction slots so some of those cycles can be useful
• Branch on any condition
• Barrel shifter
• Random number generator
• 6-tick cancel-carry-adder
• Invert
• Is-zero

I had to compromise on my 10hz goal for several reasons, including grossly reduced code density due to excessive NOP instructions due to increased pipeline depth and slow Minecraft adders. But mainly because Bedrock bugs out and the computer glitches due to lag at speeds above 2.5Hz.

The CPU should port over to Java with minimal effort, almost all the glass towers are upwards-only. The barrel shifter uses soft-inversion; frankly it's not the best design out there anyway. The RAM and ROM are bedrock-only due to downward flowing redstone glass towers, but that's just the address decoders, easy to fix.

Otherwise this thing is ticking all the boxes so far.

I'm developing a simple toolchain in JavaScript using the Bedrock scripting API.

Future plans include

• Redstone display
• 4KB RAM
• 4KB ROM
• Self-hosted development in a high level language
• Web-based emulator 

More to come...

ATTARC 1.0 World Download

Toolchain Behavior Pack