I'm currently creating a CPU in Minecraft just to prove to myself that I can. As part of it, I have 16 bytes of RAM, made with vertical one-block-wide tileable RS-NOR latches.
I currently have this (Minecraft NBT structure file) design for an output bus for this RAM that works fairly well, and fairly quickly.
Let this be the "left" side (with the bit inputs numbered)
Let this be the "front" side (with the bit outputs numbered)
Let this be the "back" side (with the bit inputs numbered)
Note that in all three cases, the numbers are on the block below the power-receiving/giving block.
Links are chained like this:
The big arrow is the direction of data flow (i.e. "forward"), while the little ones are the left-side repeaters that you saw before.
Each bit from the left is OR'ed with the correspondingly-numbered bit from behind; the output goes out the front into the behind of the next link.
Currently my design works well and only takes a few ticks per link. However, I have a semi-slow computer, and I've found that when there are 16 of these links in a row, things get a bit wonky. If I hit a lag spike, sometimes a piston will think it received a 1-tick pulse, and fail to retract its block, which turns on its output bit permanently, adding bits to the ultimate output that shouldn't be there.
(That piston is not the only one that fails to retract, all of them do it, seemingly randomly.)
If a new design is the best way to fix this, I need it to fulfill the following:
- It cannot have any extra blocks on the front, left, or back sides. (Right, top, and bottom are fair game)
- It must be 11 blocks long along the forward-backwards axis
- The 0th left input must point directly into the same block that the 0th output points out of
- The inputs and outputs must still be adjacent to each other the way they are now
- Ideally, no pistons are involved, so that no stray 1-tick pulses can mess anything up
Can I fix this sporadic 1-ticking? Or is there a better design that meets the requirements above?
Best Answer
I've come up with a design that works! First, here's a link to its Minecraft NBT structure file.
A nice feature I was able to take advantage of is the fact that the inputs actually receive power from redstone torches that have blocks on top of them, like so (RAM cell output bits numbered):
The nice thing about this is that it means repeaters can receive power from two levels, colored above in blue and black. I took full advantage of that in the input of the new RAM bus link design.
Following the same direction convention as the question, here's the "left" side:
You'll note that the levels that the repeaters take input from are duly color-coded here. The 0th bit takes input from the torch, the 1st bit takes input from the block, and so on. Important note: all of the repeaters are set to 2 ticks, to prevent 1-tick pulses from the input.
Here's the "front" side. Data passage was also split into two levels, but that has nothing to do with the RAM cell outputs, this was just done to allow redstone dust directly adjacent to be used.
Here's the "back" side:
Here's how the data flows:
Okay, this is the exciting part. Here's how data gets repeated through a link:
The redstone dust powers the bottom piston, which extends the filled cauldron to the comparator, which powers the repeater, which powers more redstone dust. Important note: The repeater is set to 2 ticks so that the next piston cannot receive a 1-tick pulse.
And crucially, here's how data gets introduced to the link from the left side:
The redstone dust on top is powered from the side inputs. This powers the block below it, which in turn BUD-powers the bottom piston. However, the top piston (marked with a !) is directly powered and extends, updating the bottom piston and extending the cauldron as if powered from behind.
This was my key realization - BUD-powering is a way to transmit redstone power directly downwards! Note that I can't just directly power the bottom piston, because that would make the top power lines intersect the guards for the bottom power lines that keep them from connecting horizontally.
Counting up all the sources of delay, data passing through the bus takes 3-4 ticks to do so - when turning on, the bit in the next link turns on after 4 ticks, but when turning off it only takes 3 since pistons retract instantaneously. And because of the 2-tick repeaters (in both passthru and input), there's no possibility of 1-tick pulses hitting the pistons, so the ultimate issue is solved. Hooray!