MC Teaser

[The Grand Nudger]

Here's some screenies from a little thing I've been tinkering with on our MC server. Punching trees is for pansies!

She's about 90% done at the moment, I'm in the process of debugging the board and getting her a program written. I still need to build a proper user input panel(currently takes binary input directly) and I've left a large chunk towards the rear for peripherals.


Some specs for those that care.

---

4bit ALU w/9 functions, 16bit RAM, She executes a function every 2 seconds, and can handle up to 20 lines of code. There are 2 7-segment displays we use to keep a handle on what she's doing. All told, she's about 100meters long and just as wide, maybe 30 meters tall.

---

Hello Dave.

---

---

Overhead

---

---

Sunrise through the bus

---

---

---

Just a few more

---

---

---

---

---

---

---

Gotta give some credit on this build to Tibs, for hosting the server, and OTNAngel for helping me wire her up.

[Tiberius]

Really cool build (even cooler when I'm flying around it).

Does anyone else notice His Noodliness in this image?

[The Grand Nudger]

To provide comparison, my builds on tekkit (a collection of mods for minecraft) generally focus on being compact and automate various mechanical tasks. Computers come packaged with tekkit so there's no reason to build them out of piles of wool..lol.

In this case, the tiny machine you see automates everything one might do that involves mining. It quarries two (but can handle up to eight)areas 64mX64m from the sky limit to bedrock, pipes everything into a sorter which separates the trash (which is recycled for a later process) from the valuables. It then processes those valuables (smelts the ore and craft-condenses them for storage) piping the output to yet another sorter which then deposits the material in a painstakingly organized (color coded no less) series of storage chests.

I also added a picture of the renewable energy source that fuels all of this. It's mostly wind (with some solar and geothermal) which prevents me from having to burn resources to collect resources - increasing my overall mining operation yield.

The Machine

---

---

The Source(tethered to the ground a few hundred meters below...my op is completely subterranean-zero above ground footprint)

---

---

[The Grand Nudger]

An overhead of two mathematical circuits.


The one on the right is pretty much a standard ripple carry adder. Leveraged a little Big O and found that my carry line was slowing me down. So, reworked her (exploiting game mechanics..after finding that a real carry look ahead was a wiring nightmare -due- to game mechanics) and got the circuit on the left. It's much faster (even at just 4 bits - and of course the more bits we need to carry the faster the design becomes compared to the one on the right). Also, as a bonus, the design was much more compact, allowing me to add a module to the front to handle subtraction in roughly the same amount of space. So, faster, more powerful, similar footprint. A much more elegant design.

For internet video game science!

---

You might notice the adder on the right still has the tool I put together to measure the delay between lines. It's the long, thin red line just to the right of the solid black one that runs between the two circuits. Essentially, that line is hooked up to an input which (when the A line is set to the binary equivalent of 15) turns on two outputs. One output is a piston with three "repeaters" in front of it, serving as an adjustable timing device. The other output is the input for the B lines binary equivalent of 1. This causes the circuit to carry a bit (because this machine, being 4 bits, can only represent the decimal numbers 1-15..and 15+1=16). That carry output is then wrapped back around to another piston set alongside the first. The way this works, is that when you hit the input for the testing device it simultaneously engages the piston behind "adjustable timing device" and causes the circuit to carry-engaging the piston behind the entirety of the circuits function. When the pistons both rise simultaneously the test device is "zero'd" and you simply count the ticks of delay you had to add to the input line, and that gives you the speed of the carry line. In this case, the carry is effectively instant - because the number returned by the testing device was equal to the number returned by the same testing device when it was applied one gate further "back" along the process. Now, I could have built a more complicated (and exact) tool out of actual clocks to determine the speed of either, but all I wanted to know was their speed relative to each other - so this dead reckoning sort of approach was sufficient for that. Had I not observed any difference between the two I would have started to wonder...and I probably would have built better instrumentation..lol.

This device was used on both designs in multiple places, the XOR gates were roughly equivalent (both XOR designs are 3 "ticks"- the ingame unit of measurement for redstone signals) but the carry line for the circuit on the right added 3 ticks, for a total of 6 ticks. The circuit on the left tested out at 3 ticks regardless of the addition of the carry line, all of this at 4 bits mind you. We might extend the circuit to 8, then 16, then 32 to see if anything changes - but for now, we'll call it "instant". As a minor aside the inclusion of the subtraction module didn't add any extra ticks because it relies on the same XOR gate with a re-routed B input.

Another interesting aside, if this sort of design could be used IRL it would amount to magic...lol. Making it effectively useless as an exercise in craft but hilariously fun as an exercise in exploiting game mechanics. The way the pistons work means that for the purposes of simulating a circuit they are instantaneous. They update immediately (before you can even see it occur) travelling even faster than the redstone signal which triggers them (which simulates signal carry speed- no less). Effectively, it causes a signal to teleport - with no demonstrable means of doing so in-game-, to a place exactly 1 meter away -in exactly the direction you choose- in a span of time that is too small to be calculated in-game.

Now......the reason any of this is useful at all (for me anyway) is that I want to ensure that each circuit I build to perform a given function is as fast as I can possibly make it, because MC computers are already dismally slow. In both designs I actually used the built in redundancy of XOR gates to speed up some tasks (by being built from universal gates, NOR or NAND - so why build another to handle either function when you can simply isolate their outputs?). Right now I'm toying with whether or not I should place the modules in-line with the input (perhaps above or below it) or wether I should bus the inputs to all modules set beside the input line (effectively performing all functions simultaneously) and the creating a command line to choose the output from the next ALU I want to build. One the one hand (inline) we have complicated but shortened input lines (redstone signals carry down the line at a set speed), and on the other we have straightforward architecture and simple input lines (but they'll have to travel farther and there is a limit to how far they can go before the game stops giving a shit and they don't work anymore). Being able to handle the inputs simply and quickly, or being able to execute quickly while possibly having input and timing issues. Decisions decisions.

---