I believe the idea is that the torch powers the block, which then powers the redstone on all five outgoing sides, in the same way that a wire leading into a solid block powers it and hence affects a torch attached to the other side. I still run into this by accident more often than I do it on purpose, though.
Ahruman is right. It is a very important property for making compact logic gates and circuits, most of which would not function without it. Notice how on the left design the wire forms a plus shape. This means it can transmit power to any adjacent block instead of just one direction opposite from the torch, and the wire will not automatically turn into the block. You also can have 4 protected outputs from that one torch, so you don't have to worry about what you are plugging into messing up your outputs going in the other directions, since they are all independent. A final point, is that the left design has a height of 2, and the middle design has a height of 3. For a 2 high device, this will almost always be used with a side torch with no wire on top of the input block, or you would get a pulsar.
Vertically oriented modules? I never really thought about that, but it seems very space efficient, since horizontal buses are a lot more efficient than vertical ones. Someone should convert all existing designs to such, it'd be quite convenient.
We got a start on that discussion over here. Small RS NOR latches and various applications of simpler logic gates and vertical repeaters.
The torches that you use to make vertical circuits don't interfere with other adjacent torches, so it opens up more options for packing circuits tightly, at the expense of complexity, torches, and latency.
Vertical D flip-flop, 1x6x7, level triggered on the assumption that a pulse is easy to distribute to several latches. It can be 'bent' at various points so it's an L-shape when viewed from above. This one doesn't have any special ability to be placed close to other circuits and isn't input-protected.
Vertical XOR, 1x7x7, can be placed directly adjacent to another vertical XOR of the same design if offset by 3 spaces horizontally, for a total volume of Nx10x7 for a block of N independent XOR's. Designed to be a low-volume solution that accepts signals from a bus of parallel signals that are 1 square apart. Inputs are protected.
There are lower volume individual XORs, but this one saves a lot of space if you want your signals to be 1 square apart horizontally.
If your signal bus lines are 2 squares apart, this 3x6x5 XOR can be placed 2 squares away from another XOR of the same design, so the XORs can be placed directly in line with your bus. Output is at the bottom of the XOR. Inputs are protected. I need to make a less epilepsy-inducing .gif.
Vertical clock, pulse width 9, period 18, size 1x5x6. It's pretty easy to expand to adapt to slower speeds. Works only if built east-west. I think if you build it north-south, it's a... 4/8-clock?
I'm not 100% sure of when the NS vs EW propagation speed glitch applies, so I haven't listed definite speeds for these designs. You can usually abuse it to make designs faster or slower.
I made your flip-flop a little smaller and used the same labels.
now its only 5X5X2
The best way to use the output and input is to put a block underneath Q and on top of T.
it will operate with a 4 clock while facing north, but requires at least a 6 clock while facing west.
I just checked and it is possible to flip the edge detector so that the input and output are on opposite sides.
I would love to see these designs added to the wiki - as well as Zorac's latest vertical contributions! This is awesome stuff, everyone.
Vertical D flip-flop, 1x6x7, level triggered on the assumption that a pulse is easy to distribute to several latches. It can be 'bent' at various points so it's an L-shape when viewed from above. This one doesn't have any special ability to be placed close to other circuits and isn't input-protected.
You can reduce that to 1x6x6 simply by shifting the right half of the diagram down one block. Tested it, worked fine.
…am so addicted to playing with the simulator now, I keep forgetting to build & do stuff in the game…
But anyway, I put together a combination lock & was hoping somebody could help me shrink it down a bit as right now it is much too large for it's own good.
<snip>
hrm, was going to attach the schematic file for easier use but the uploader hates me. so, heres a link to it: http://thesizer.net/files/Combo5btn.zip
Does anyone think Notch might have recently modified redstone behavior?
There are a few strange behaviors I've been seeing:
- When I right-click on a redstone line with dirt, it places the dirt above the redstone, in air. (Did it always do that?)
- I can't get the 1-wide pulse generator from the wiki to work anymore.
- Some repeater propagation times are behaving oddly in a way that indicates a timing bug other than the usual NS vertical delay trick. I built a variable-width pulse generator and tried sending single pulses down chains of repeaters. The pulses don't propagate down all the repeaters as expected, but die off, with longer pulses surviving through more repeaters.
It appears that the trailing edge of the pulse is catching up to the front edge and the pulse eventually dies once it passes through enough repeaters. That one baffles me, because it implies that torches turn off somehow faster or slower than torches turn on for he configurations I've tried.
I'm going to have to find a way of precisely timing pulses so I can determine which repeater arrangements shorten pulses and by how much. If nothing else, that implies that there's another way to synchronize signals besides the NS trick.
A one-tick pulse is not sufficient to deactivate a torch - by the next tick when they would actually react to it, it's gone again, so they don't change state. Try adding an extra inverter in the delay chain of your pulse generators to make it two ticks (you'll probably have to invert the input and output to it as well), or use a north/south stacked pair to add a single tick delay without inverting it?
I’ve found the direction-dependent behaviours confusing, and even irrational, but I think I know what’s going on. I’ve been thinking of redstone updates as a two-pass process: first update the torches, then update the wires based on the torches, as two passes in a single tick. (I think this is how Redstone Simulator works; Baezon?)
Minecraft, I now believe, does it differently: clear the wires, then update the torches and propagate charges in one pass. When it does this, it passes from northeast to southwest – in Minecraft’s coordinate system, from low X and Z values to high ones. This opens some avenues of exploration:
[*:3kh63bir] Does it also pass from low values to high ones? Predicition: yes. A vertical version of xgkkp’s test would work downwards, but not upwards.
[*:3kh63bir] Is the traversal X-major or Z-major? That is, after a given torch is updated, does one to its north get updated before one to its east? What type of circuit would detect this distinction?
[*:3kh63bir] Is the traversal one sweep across all chunks in range, or per-chunk? What type of circuit would behave differently at chunk boundaries if it was per-chunk? Could a boundary detector be made that works in both directions at once? Could boundary effects be exploited?
I just tried sending a 3 tick (I think) pulse through a long chain of horizontal inverters. (block, torch on the side, single redstone dust leading to the next inverter). It passed through 7 or 8 repeaters in each direction (all chained together into one giant switchback) and definitely was not shortened.
I tried it again, placing unnecessary redstone dust on top of each inverter block. The very brief pulse was still transmitted without shortening.
The behavior we're seeing might be directional, but it's also specific to certain arrangements of redstone and/or torches, and there definitely isn't a universal directionality to all redstone resolution.
I suspect at the root of this we will see one or a few glitches as specific as the known NS glitch.
I propose that we look more closely at the interactions between torches on the side of blocks vs torches on top of blocks. Since the rules for vertical torches are slightly different than for horizontal torches, maybe each one is getting their own step in the state machine. (like, update redstone, update horizontal torches, update vertical torches?)
Okay, I have one example circuit that definitely repeats ON pulses faster than OFF pulses, and the behavior IS directional.
Eight repeaters is enough that you can easily see the speed difference. (this is my runway light animation repeater, where the goal was to get the vertical torches adjacent.)
I've tried it pointing all four directions and it only showed the glitch when pointed east or west. I estimate that the ON pulse traveled about twice as fast as the off pulse. (ON and OFF referring to the vertical torch states.)
Place a block above the last vertical torch and you can run a redstone wire back to the first torch, making this a fun clock design to watch cycle itself, and trivial to see that the east- and west-pointing ones ares running faster than the north- and south-pointing ones.
Here's a slightly shorter version of my 2x4x5 D-latch. This one is 2x3x5, but unlike the other one it can't be chained horizontally so if you're using them side by side you're better off using that one.
Working more on my cpu. Since my program counter is 9-bit, I needed a a separate adder. Then I wondered what it would take to make it a decrmenter as well. So here it is.
Essentially its an xor that takes the add bit of it and outputs it to the input of the next xor. I put an inverter at the end, and fed it into another half-adder you now have a decmenter! Good for a stack pointer.
I also added a +2 function. I figure it be faster to increment a program counter by 2 for a skip rather than execute a nop on a skip.
Now if I can just figure out how to put in a flip-flop and make it a self incrementing regester:P
PS - What font does everyone use for putting the text in? I can't seem to find it.
This may be the easiest question some of you circuit geniuses answer all day.
I checked out the wiki about MineCraft circuit designs and the descriptions are very, annoyingly technical. Based on the wordings there, I built my first T flip-flop. It's cute, but that's not at all what I thought I'd be getting. Dealing with Q, not-Q, and all that garbage is not helpful and I can already use diagrams on the wiki as a guide; what I need is a simple English explanation of what D flip-flops and JK flip-flops actually do. Examples of their uses, if clear, may even be enough. Just trying to avoid more wasted effort. Thanks for your time, guys.
This may be the easiest question some of you circuit geniuses answer all day.
I checked out the wiki about MineCraft circuit designs and the descriptions are very, annoyingly technical. Based on the wordings there, I built my first T flip-flop. It's cute, but that's not at all what I thought I'd be getting. Dealing with Q, not-Q, and all that garbage is not helpful and I can already use diagrams on the wiki as a guide; what I need is a simple English explanation of what D flip-flops and JK flip-flops actually do. Examples of their uses, if clear, may even be enough. Just trying to avoid more wasted effort. Thanks for your time, guys.
D Flip-Flops are used for memory. It's used instead of an RS-NOR latch if you want to store both on and off data, and control when it is saved (like a save button or something). JK Flip-Flop, I'm still figuring out...
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
We got a start on that discussion over here. Small RS NOR latches and various applications of simpler logic gates and vertical repeaters.
The torches that you use to make vertical circuits don't interfere with other adjacent torches, so it opens up more options for packing circuits tightly, at the expense of complexity, torches, and latency.
Vertical XOR, 1x7x7, can be placed directly adjacent to another vertical XOR of the same design if offset by 3 spaces horizontally, for a total volume of Nx10x7 for a block of N independent XOR's. Designed to be a low-volume solution that accepts signals from a bus of parallel signals that are 1 square apart. Inputs are protected.
There are lower volume individual XORs, but this one saves a lot of space if you want your signals to be 1 square apart horizontally.
If your signal bus lines are 2 squares apart, this 3x6x5 XOR can be placed 2 squares away from another XOR of the same design, so the XORs can be placed directly in line with your bus. Output is at the bottom of the XOR. Inputs are protected. I need to make a less epilepsy-inducing .gif.
Vertical clock, pulse width 9, period 18, size 1x5x6. It's pretty easy to expand to adapt to slower speeds. Works only if built east-west. I think if you build it north-south, it's a... 4/8-clock?
I'm not 100% sure of when the NS vs EW propagation speed glitch applies, so I haven't listed definite speeds for these designs. You can usually abuse it to make designs faster or slower.
These are all in my redstone playground save game.
I would love to see these designs added to the wiki - as well as Zorac's latest vertical contributions! This is awesome stuff, everyone.
You can reduce that to 1x6x6 simply by shifting the right half of the diagram down one block. Tested it, worked fine.
I just finished my 1-wide combo lock:
http://www.megaupload.com/?d=CZNXXDRT
(if at first it starts blinking, just press the button on the far right)
Code is 5-6-7-8 and then hit Enter (far-right)
There are a few strange behaviors I've been seeing:
- When I right-click on a redstone line with dirt, it places the dirt above the redstone, in air. (Did it always do that?)
- I can't get the 1-wide pulse generator from the wiki to work anymore.
- Some repeater propagation times are behaving oddly in a way that indicates a timing bug other than the usual NS vertical delay trick. I built a variable-width pulse generator and tried sending single pulses down chains of repeaters. The pulses don't propagate down all the repeaters as expected, but die off, with longer pulses surviving through more repeaters.
It appears that the trailing edge of the pulse is catching up to the front edge and the pulse eventually dies once it passes through enough repeaters. That one baffles me, because it implies that torches turn off somehow faster or slower than torches turn on for he configurations I've tried.
It's always done that. Very convenient for making contraptions.
I'm going to have to find a way of precisely timing pulses so I can determine which repeater arrangements shorten pulses and by how much. If nothing else, that implies that there's another way to synchronize signals besides the NS trick.
Minecraft, I now believe, does it differently: clear the wires, then update the torches and propagate charges in one pass. When it does this, it passes from northeast to southwest – in Minecraft’s coordinate system, from low X and Z values to high ones. This opens some avenues of exploration:
[*:3kh63bir] Does it also pass from low values to high ones? Predicition: yes. A vertical version of xgkkp’s test would work downwards, but not upwards.
[*:3kh63bir] Is the traversal X-major or Z-major? That is, after a given torch is updated, does one to its north get updated before one to its east? What type of circuit would detect this distinction?
[*:3kh63bir] Is the traversal one sweep across all chunks in range, or per-chunk? What type of circuit would behave differently at chunk boundaries if it was per-chunk? Could a boundary detector be made that works in both directions at once? Could boundary effects be exploited?
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
I tried it again, placing unnecessary redstone dust on top of each inverter block. The very brief pulse was still transmitted without shortening.
The behavior we're seeing might be directional, but it's also specific to certain arrangements of redstone and/or torches, and there definitely isn't a universal directionality to all redstone resolution.
I suspect at the root of this we will see one or a few glitches as specific as the known NS glitch.
I propose that we look more closely at the interactions between torches on the side of blocks vs torches on top of blocks. Since the rules for vertical torches are slightly different than for horizontal torches, maybe each one is getting their own step in the state machine. (like, update redstone, update horizontal torches, update vertical torches?)
Eight repeaters is enough that you can easily see the speed difference. (this is my runway light animation repeater, where the goal was to get the vertical torches adjacent.)
I've tried it pointing all four directions and it only showed the glitch when pointed east or west. I estimate that the ON pulse traveled about twice as fast as the off pulse. (ON and OFF referring to the vertical torch states.)
Place a block above the last vertical torch and you can run a redstone wire back to the first torch, making this a fun clock design to watch cycle itself, and trivial to see that the east- and west-pointing ones ares running faster than the north- and south-pointing ones.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEssentially its an xor that takes the add bit of it and outputs it to the input of the next xor. I put an inverter at the end, and fed it into another half-adder you now have a decmenter! Good for a stack pointer.
I also added a +2 function. I figure it be faster to increment a program counter by 2 for a skip rather than execute a nop on a skip.
Now if I can just figure out how to put in a flip-flop and make it a self incrementing regester:P
PS - What font does everyone use for putting the text in? I can't seem to find it.
My new version of Redstone Simulator
Main Code Site: http://code.google.com/p/red-stone-simulator/
It almost looks like there's a specific program they all use. Also, how do you get it to display vertically?
I use Arial Black (14 pt, bold). To my knowledge there isn't a program to put these in, someone just started using it and everyone else copied them.
I checked out the wiki about MineCraft circuit designs and the descriptions are very, annoyingly technical. Based on the wordings there, I built my first T flip-flop. It's cute, but that's not at all what I thought I'd be getting. Dealing with Q, not-Q, and all that garbage is not helpful and I can already use diagrams on the wiki as a guide; what I need is a simple English explanation of what D flip-flops and JK flip-flops actually do. Examples of their uses, if clear, may even be enough. Just trying to avoid more wasted effort. Thanks for your time, guys.
D Flip-Flops are used for memory. It's used instead of an RS-NOR latch if you want to store both on and off data, and control when it is saved (like a save button or something). JK Flip-Flop, I'm still figuring out...