2

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) Left side of RAM bus link Let this be the "front" side (with the bit outputs numbered) Front side of RAM bus link Let this be the "back" side (with the bit inputs numbered) Back side of RAM bus link Note that in all three cases, the numbers are on the block below the power-receiving/giving block.

Links are chained like this: Top view of two chained links 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. Flip-flopped piston (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?

3
  • Instead of fighting the block dropping behavior, consider embracing it. Or just set repeaters to 2 ticks.
    – SF.
    Commented Jul 27, 2020 at 12:10
  • @SF. I set a bunch of repeaters to 2 ticks and added some 2-tick repeaters (MC NBT), but the issue persists because there are 2 pistons in sequence on most bits. 2-ticking the first fixes it, but its 0-tick retraction 1-ticks the second. Your "embracing" option is elegant but is not proof against bitflips from 1-ticks in the inputs. Is there a way to use at most 1 piston per bit?
    – AbyxDev
    Commented Aug 2, 2020 at 11:00
  • Yes, there's even a way to use 0 pistons per bit except for the final output of the entire bus. See the paragraph on pulse logic on the wiki, and the examples near the end of the page. You'd probably need to redesign a bit of logic, as your fundamental basic operation is now XOR instead of OR, but as long as you read only one memory bank at a time and deactivate the prior one before activating another, it makes no difference. Pulse logic, due to to use of rails (activator and powered) allows some deep compacting.
    – SF.
    Commented Aug 3, 2020 at 8:47

1 Answer 1

0

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): RAM cell output style 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: RAM bus link data input style 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. RAM bus link output style

Here's the "back" side: RAM bus link repeat input style

Here's how the data flows: RAM bus link top view

Okay, this is the exciting part. Here's how data gets repeated through a link: RAM bus link passthru method 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: RAM bus link data input method 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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.