Tag Archives: Redstone

Of course, the most interesting thing about Minecraft for us STEM Hacker parents is redstone. Redstone — more precisely redstone dust (but I’ll just say “redstone”) — is basically wiring, and combined with lights and levers and torches, and a few other do-dads, pretty much enables you to build any sort of digital computing device that you can figure out…although you’re almost literally building it from sand! Given the low-level-ness of the whole thing, and some other annoying problems — mainly that redstone (dust) is highly resistive as compared with real wires, and everything is physical, so you’re running highly resistive and self-interacting wires all over the place! — you really have to think like a VLSI engineer rather than like a computer scientist. Yet there are folks who build quite amazing computing machines — like complete huge Turing machines!, and other insanely complex devices(this one’s actually a playable Pong in redstone, and this one’s an utterly insane graphing calculator! — in Minecraft. But I’m guessing that those folks (a) aren’t trying to collaborate on the project with a 7-year-old, and (b) have WAY too much time on their hands.

(There are ways to think in Minecraft like a computer scientist — specifically, you can actually program the world in Python! But I’ll get to that another post.)

Anyway, so Leo and I set out to do something pretty modest, create a binary counter using adders. We had worked through how a redstone adder works based on this very good video. (I highly recommend watching that video to get a very good sense of how redstone works if you don’t already know.) So we designed a counter. The design is to use two adders linked in a ripple carry configuration, and a clock whose tick causes the adders to latch their output and to pass the latched output back to their inputs, permanently adding 01 on each cycle.

Here are the two adders linked in a ripple carry configuration and with a manually-operated output latch — no clock or fed-back inputs yet:

There’s a lot to see here, and watching the video linked above about adders will help a lot to understand what’s going on here, if you care. But one thing to notice is the latch repeater (on the rightmost side). Notice that the redstone just ahead of the repeater is going dim. This is one of the really annoying things about redstone: the signal is both slow, and fades out after 15 blocks, so you need to add repeaters every once in a while. It’s also undependable in terms of timing, causing all sorts of noise in the signal. As a result, you need to annoyingly put repeaters and latches all over the place, just to get your signals from A to B reliably. But, the above manually-operated ripple-carry adder and latch circuit actually does work.

Okay, so now to the counter. All we should have to do is to add a clock and feed the outputs back into the inputs (and set 01 as a permanent input), right? Well, all that isn’t as easy as it sounds.

First to the clock. We did the clock by creating a railroad of a certain length, so that the car runs continuously, and each time around sends a signal to our counter. Here’s the railroad:

In the below you’ll see this in various configurations (and with various animals sitting the car — turns out that animals like to get into the railcars!) This worked pretty well. The repeater next to the left track picks up the signal when the car passes it and sends it to the latch, which stays on for a few seconds and then cycles off. This is our signal. We can make the clock-tick arbitrarily long by just making the track loop longer. (We had discovered this trick while trying to make a roller coaster.)

Okay, so now we have to get the latched outputs back to the input side of the adders. This wasn’t so easy, and we tried a couple of different configurations before settling on one that was not overly tortuous. Here’s an early one:

This is a little hard to parse visually, but what’s happening is that the return signals are climbing up to a pair of high-wires (literally!) that bridge them back over the adders and to then land them down a bunch of steps to the correct input. (Note that this pic is backwards v. the above pics; here the inputs are on the right. The clock is at the back, slightly hidden.) This required so many staircases and repeaters that it was too hard to debug, so we ended up with this simpler design:

(This one’s in the “normal” orientation that the first pics above were: Inputs on the left, outputs on the right.)

Here the return signal only has to bridge the ripple carries, rather than having to bridge the whole adder, which required a lot less stair-cases, and many fewer repeaters. Note the pig wandering around on the input, and the sheep that is now riding around in the rail car!

This configuration actually sort of worked, and it’s fun to watch it run. Here’s another view of it at a different phase just so that you can see that the system is actually clocking:

Unfortunately, timing problems with redstone repeaters made it unreliable. It really needs to have another set of latches on the input side. That would be easy to wire up now that we have a reliable clock, but, to be honest, (a) I’m collaborating with a 7-year-old, and (b) NO, I do NOT have too much time on my hands!