T Flip-flops Deleted?[]
Why did someone delete everything about T flip-flops? And why was the circuits page split up? This seems really stupid to me. Mister Momotaro 16:36, 27 October 2012 (UTC)
- Probably vandalism, it seems to be back now. I took the liberty of adding a proper topic header to your comment. --Mental Mouse 01:03, 13 December 2012 (UTC)
- I don't think it was vandalism, since it was done by Goandgoo. It looks like he accidentally removed some of the Flip-Flop info when he removed the pulse components. And the circuits page was split up because it was insanely long and cluttered, per consensus of various discussions. —Munin295 ·
· 05:08, 13 December 2012 (UTC)
- I don't think it was vandalism, since it was done by Goandgoo. It looks like he accidentally removed some of the Flip-Flop info when he removed the pulse components. And the circuits page was split up because it was insanely long and cluttered, per consensus of various discussions. —Munin295 ·
High and low[]
The section on D flip flops and latches uses the terms "high" and "low" for what seems to be on and off. Particularly now that signal strength is sometimes relevant, this is incredibly confusing. I wanted to check here first to make sure that on and off is the actual intended meaning, and that if I changed it I wouldn't make the article inaccurate. Monchoman45 03:32, 6 February 2013 (UTC)
- Relatedly, the JK flip flop section uses 1 and 0, which isn't as confusing, but could be difficult to pick up on for someone who's never heard of binary. Monchoman45 (talk | contribs) 04:06, 6 February 2013 (UTC)
- "High" and "low" are common terms when it comes to digital signals, more than "on" and "off" IMO (although that might depend who you talk to). I don't think they're confusing, even considering the quantized signal levels we have now (as long as you know the subject is a digital system—if it's an analogue system, "high" and "low" have no meaning if not defined anyway). OTOH, terminology should *definitely* be defined somewhere among the redstone articles on the wiki, and editing the article here for consistent terminology usage is an improvement (if needed, haven't read it in a while), but I would favour "high" and "low" rather than remove it.
- Also, 1 and 0 are more ambiguous than "high" and "low"—you can represent logical 1 with redstone low (= 0 signal) and logical 0 with redstone high (>0 signal). You can also represent it the other way around, logical 1 = redstone high, logical 0 = redstone low. If you're dealing with binary-coded data, you have to know what (redstone) means what (binary) in your design. Some inverted-input or active-low redstone circuits could be said to be a trivial example of that. Laogeodritt [ Talk | Contribs ] 05:01, 6 February 2013 (UTC)
- I think it makes sense to introduce/define redstone terms on the main Redstone Circuits page, and then when the term is used on another page for the first time (per page, or per major section, or whatever seems right), simply link it to the main definition. I have an elaboration on power level in my user space (Redstone Circuits 1.5) ready to go once 1.5 is finalized (articles are supposed to describe the published version of Minecraft, which is still 1.4.7 currently, where power level is only significant for redstone wire).
- I prefer "on" and "off", simply because we're not writing for electrical engineers, but for the Minecraft community, some of whom are kids or non-native English speakers. "High" and "low" aren't too difficult to understand, but most people think of electricity (the usual metaphor for redstone) as being on or off (light bulbs, appliances, etc.) rather than high or low.
- We usually don't worry about the output power level of a latch -- if it's on, it's on (whatever the output power level), otherwise it's off. So it's probably best to just keep discussing the circuits in terms of on and off, and only mention their output power level as an additional consideration if it's important for some reason (most of the circuits have their output right out of a torch though, so probably unlikely). Capacitors (circuits that hold an input power level until reset) will obviously need such a discussion.
- —Munin295 · · 08:48, 6 February 2013 (UTC)
- The organization of definitions makes sense to me. I'd say that since this is the kind of article that will very often be accessed randomly, not read sequentially, it makes sense to link terminology once per major section—even for someone who knows redstone and needed to look up one of the basic designs, they could come across terminology they don't habitually use.
- With regard to "on" and "off", while I don't like them as much for standard terminology (sounds more device-oriented than signal-oriented to my ear), I can understand the accessibility point of view. I've been working with electronics and programming for a few years now, so I don't really have the best perspective of players who aren't familiar in digital circuits or electronics.
- Off-topic: Capacitor circuits, huh? Interesting adaptation of the word **capacitor** to redstone.
- Laogeodritt [ Talk | Contribs ] 03:51, 7 February 2013 (UTC)
- "...this is the kind of article that will very often be accessed randomly..." That's a very good point. Could justify parenthetical summaries of some terms, in addition to linking to full definitions.
- "device" vs. "signal": There really are no signals in redstone circuits -- it's a cellular automaton. Signals, pulses, etc. are just useful metaphors for closely-associated things that are happening too quickly to discern discretely. : )
- The "capacitor" circuits I've seen actually act more like a superconducting loop (feeding the same power level around in a comparator loop) than an electronic capacitor. I wonder if we could simulate electron flow using items through hoppers -- then build a circuit that would cause items building up in one hopper to "push" items out of a nearby (but not adjacent) hopper, and items flowing out to cause the other hopper to pull other items back in? That would be tough -- each hopper in the wire would have to compare the fullness of both its neighbors to decide which way to push items... Actually, I don't think I've seen two-way hopper pipes. Maybe with two lines of hoppers going in each direction with double chests every other space to have room to tile 1-wide processing circuits... Hmmm... Actually, it would probably be easier to reverse the direction of water in an item channel...
- —Munin295 · · 07:12, 7 February 2013 (UTC)
- (Switching to non-threaded indentation for readability).
- With regard to random access, I would say that's even more of a reason to link, not to repeat—summarizing or repeating definitions would be even more redundant than for a monolithic article. I would go with the Wikipedia convention here of relying on article/section links to explain concepts that are related to the article subject, and sticking to what needs to be explained on the subject itself.
- With regard to "signal", I would disagree (on a fairly academic point—it doesn't matter in any practical sense), in that I would define "signal" not as any physical realization or entity (whether in a Minecraft or real-life context), but any function of time carrying information (including just a DC/constant value—"on" and "off" is information). I think your argument of signals as an abstraction apply to lumped linear circuit models too. In the case of redstone, a "signal" would be physically realized as the state of a redstone node over time. (Again, doesn't matter in any practical sense—I'm not trying to be pedantic in arguing the terminology issue earlier, only bringing up an academic point.)
- I'm aware of the electronic capacitor's behaviour (I do more analogue than digital, after all =] ), I just thought it was an interesting leap of logic into the redstone capacitor circuits you described. The latter sound more like a sample-and-hold circuit—which is essentially designed around a capacitor. I can't help but think that hopper-based flow simulations would be either incredibly slow or a very low-resolution quantization...
- (Also, yay for remembering basic formatting wiki syntax on my third try! I've been using Markdown and LaTeX too much lately, I've forgotten wiki syntax...)
- Laogeodritt [ Talk | Contribs ] 00:34, 8 February 2013 (UTC)
Piston changes in 1.5[]
Am I the only one who is annoyed by the removal of the 1-tick-functionality in sticky pistons? There are so many complex and simple constructions like elevators or T-FlipFlops that do not work any more. And there is no upside because you had to do specific things to receive this behavior... There was absolutely no need to fix that bug, because it wasn't a bug (any more at least)... 91.89.80.31 16:01, 15 March 2013 (UTC)
- The 1-tick functionality of sticky pistons has not been removed, it's only that some 1-tick pulse generators have been broken. Two 1-tick pulse generators that still work are the circuit breaker (dust, block over sticky, repeater) and the repeater lock pulsegen (two repeaters facing into dust and sideways repeater).
- —Munin295 · · 16:22, 15 March 2013 (UTC)
- That's good news! I'll have a look at that.. thank you! 91.89.80.31 16:42, 15 March 2013 (UTC)
New T-Flipflop Design[]
With comparators, it is very easy to use a dispenser with a bucket of water or lava as the latch of a T-Flipflop. I don't have the means to make the diagram myself, so I will try to describe it here.
A dispenser with one empty bucket attached to a comparator emits a signal strength of 1, however a bucket of water/lava makes it emit strength 2. As we all know, a signal of any length will fire the dispenser once, either retrieving or placing the liquid block depending on its current state.
B--DOO
C
|
|
R
B is a button, or other input device to activate the t-flipflop. D is the dispenser, it must be pointing toward the Open space (O) if sideways, or you can place it facing down with a single space empty underneath.
C is the comparator, which requires two blocks of redstone wire be placed before placing the Repeater (R). Each press of the button will turn the repeater on or off. –Preceding unsigned comment was added by 173.81.52.64 (talk) at 20:12, 11 April 2013 (UTC). Please sign your posts with ~~~~
- Sounds like it would work. Containing the dispensed lava/water would probably be the issue. However, in a smaller space you can make Grizdale's dropper TFF, which doesn't depend on output strength.
- Anyway, this talk page is for discussing the Latches article. The forums would be a better place to talk about new designs. —Munin295 · · 21:14, 11 April 2013 (UTC)
Sub-pages reaching schematic limit.[]
"RS Latches" in particular is getting harder to save. I'm considering merging it back into Memory, using Loadbox for the separate schematics. Thinking ahead, this will make for a long article. And I just checked, LoadBox doesn't work inside a LoadFile. --Mental Mouse 13:08, 21 May 2013 (UTC)
- Agree. I think moving the majority of the content back into all the redstone articles should be a goal (probably with most or all the schematics offloaded individually or in small thematically-linked groups with LoadBox) -- it makes it a lot easier to scan down an article looking for what you want. Long articles are fine, as long as its a cohesive topic (which this would be, unlike say Tutorials/Mechanisms).
- —Munin295 · · 17:40, 21 May 2013 (UTC)
- Well if we re-merge them, there's no "probably" about offloading the schematics, and LoadBox seems to be the best tool we have for that. At least the headers will work properly. --Mental Mouse 20:04, 21 May 2013 (UTC)
Grizdale design A schematic wrong[]
The schematic for the A design for the Grizdale T Flip-Flop design shows a button on the bottom dropper, but the button must be on the top dropper. Zaralith 02:02, 19 June 2013 (UTC)
- Correct. I've revised the schematics, and just stated the requirement in the caption, rather than trying to represent it with a hard-to-see button.
- —Munin295 · · 06:08, 19 June 2013 (UTC)
Circle of Stones memory circuit[]
I've been looking through the redstone pages for a memory circuit I've used a few times and can't seem to find it. I'm sure it would count as a memory circuit, because it remembers which of 12 values it's currently in. That's gotta go under the "memory" heading, right? Anyway, it uses a "circle" of stones (actually a square, and I usually use gold blocks rather than stone just to show off) with a pit 1 square below it with a powered redstone wire. The stones are acting as circuit breaks. Pistons juggle the stones, advancing them 2 spaces (well the whole thing fires twice to do that). Mixed in with the gold blocks is a brick slab (the "impurity" in the gold) and whatever position that slab is in fails to break the circut. The only thing here I saw that mentioned pistons just mentioned using them to move a block between 2 spaces for an on/off effect. –Preceding unsigned comment was added by 24.68.154.229 (talk) 03:48, 9 December 2013(UTC). Please sign your posts with ~~~~
- Yes, this page needs work. What you're describing sounds like a "piston tape", a specific form of "counter" (a memory circuit which can hold more than two states). —munin · · 04:09, 9 December 2013 (UTC)
- Thanks for the reply and for the link. There's differences between that and what I built but I agree they're in the same general catagory. I think his is better, although mine has a smaller footprint. There's 2 rather inconsiquential differences but I think the one difference that does matter is that in mine it's only one "tape" (band?) and it's trying to draw power off 12 points not one (and failing at all but one of those points).
- Also since it's only 1 band I think if I try to expand it to bigger numbers the footprint will grow exponentially while his multiple band design won't. I designed mine when I was a bit of a newb at redstone. I actually learned a lot in those 3-4 days building that working clocktower (warning: clocktowers become inacurate the moment you sleep through the night and I've never been able to figure out a way to auto-adjust for that so if you're thinking of building one yourself be warned that road ends in heartbreak :)
- 24.68.154.229 13:18, 10 December 2013 (UTC)
- My link was to search results, not one specific video, so there should be lots of different kinds of piston tapes in those results. Lots of possibilities. :)
- Use a daylight sensor to detect whenever it gets dark enough to sleep, and then when it gets light again (whether due to sleeping or just the night ending), reset your clocktower to "dawn" time.
- —munin · · 18:19, 10 December 2013 (UTC)
New T Flip-Flop[]
I have a new T Flip-Flop.
99.9.245.107 14:52, 15 November 2014 (UTC)
- It's a mere variation of TFF design M, which, I think, dates back at least to 1.3; I don't see any reason to add your design. Everyone knows that a redstone block could be used instead. --Naista2002 ♦ 15:14, 15 November 2014 (UTC)
What about hopper-dropper T flip-flop? It's really simple and customizable.[]
User:Rkit/Hopper-dropper-TFF
- Grizdale's TFF is already listed and would usually be a better choice, but feel free to add yours (though the second is no longer a T Flip-Flop, but getting into shift register territory). —munin · · 21:38, 27 July 2016 (UTC)
- It's indeed a nice design for a shift register. Thanks for sharing it! --PHO (talk) 04:41, 29 July 2016 (UTC)
New RS Latch and 'Radio Button' Latch Designs[]
By using repeaters and/or torches to power the set and reset inputs, this design can be tiled side by side. It's also easier to tile every 2 blocks. The only issue is that the clock line must be on by default and pulse off to reset, as this design takes advantage of quasiconnectivity.
'Radio Button' Definition[]
A Radio Button Latch is a circuit that only holds one input at any given time. It can be made using D latches hooked up so the clock input activates when any Data Line is activated, or by using RS latches hooked up so each input sets its respective latch, and resets all the others. I have named it as such in reference to the circular radio buttons which only allow you to choose one option you've probably seen in an online form or test somewhere. This latch type is useful whenever you can only have one input active at any given time. In particular, it can be a viable alternative to item frames when you have more or less than 8 options.
This design can be tiled for up to 13 different options on each side of the reset pulse generator. If the input lines have at least one block of space between each of them, it is possible to power each line with a torch by replacing the leftmost repeater with a redstone dust and placing a torch underneath the block supporting it, attached to any block except one that powers the clock line. Alternatively, in the same conditions where you can place a torch underneath a block, you can also place a button somewhere else on the block to test the circuit.
The question mark can either be a repeater or a redstone dust, depending on the spacing of the circuit and what you need when building this circuit. A button which powers only the bottom part of the clock line can be used as a reset switch for the whole circuit. Care must be taken to ensure only one repeater can be activated at a time, otherwise multiple outputs are possible.
I've built this circuit and its variants so many times I've pretty much memorized how to do it. I've experimented with how to build other such latches like this, but this happens to be the smallest and I'm going to stick with it as space is at a premium for the build I'm using these for.
LordTeague (talk) 21:38, 26 December 2016 (UTC)
Key[]
You need to put a key to the diagreams on EVERY page. I come here and look at the diagrams, but i have no idea what some of the different coloured squares are. It makes all these heroic efforts at documentation futile, because i cant reproduce the cicuits.
172.31.16.69 23:28, 15 November 2017 (UTC)
- Every diagram has a little blue question mark icon which links to the Help:Schematic page. —munin · · 13:22, 16 November 2017 (UTC)
The 2 piston TFF in the article isn't reliable[]
Looking at the 2-piston T flip flop design in the article, I couldn't convince myself that it would work. When I built it in Minecraft, I was correct: it does flip and flop sometimes, but not reliably. Sometimes it stays where it is. I came up with a 2-piston T flip flop (on the right) that's reliable but way more complicated, involving a piston edge detector and two 1-piston AND gates to drive the 2-piston flipperflopper, but it's rather sprawling and not at all compact at 9x9. I could have made it more compact with non-piston edge detector and AND gates but I wanted to see what I could do with pistons.
I suggest removing the existing one from the article, or at least out of the "best in class" section. I'm not suggesting to put mine in. It's just that the one in the article doesn't really work. Amatulic (talk) 01:07, 11 March 2018 (UTC)
- The design shown in this schematic is very redundant, because it effectively employs two (!) sticky-piston-based TFFs just to move additional blocks. I think using four pistons to move a block in a circular fashion is better for a multi-piston TFF, however it would be tricky to get its output. I will investigate this idea for an upcoming Russian article on memory circuits. — BabylonAS (talk | ru.Wiki Admin) 16:42, 1 June 2018 (UTC)
- Yeah. As you can see, such thing looks quite cumbersome to manage, and I had to use a cauldron to mitigate any quasi-connectivity surprises. But probably it would be possible to use gravity-obeying blocks with pistons, analogous to Grizdale’s TFF which uses a hopper. Click on the screenshots to enlarge.
View 1
View 2
- — BabylonAS (talk | ru.Wiki Admin) 17:04, 1 June 2018 (UTC)
- Oh, my. Brilliant work, and makes efficient use of space... but the same efficiency as mine in terms of needing a total of 5 pistons in each design. Amatulic (talk) 17:27, 1 June 2018 (UTC)
- You needed three sticky pistons, and my design only needs one (not counting one with the cauldron... how did you actually miss that? I used six pistons) but in both cases there’s a pulse limiter/generator, which may be replaced by another of its kind that doesn’t use a piston). While I’m grateful for your response, I’m not going to call this design an advance, however I do confess that it was a good try for a new (at least, for me) TFF concept. Also, something that I forgot to say yesterday. While you have removed the load-box template with Design O (which I call quasi-connectivity TFF, because it uses this trick), the textual description is still present. In my opinion, it is better to place this particular TFF under obsolete designs. Finally, the way you have placed replies is weird. — BabylonAS (talk | ru.Wiki Admin) 13:05, 2 June 2018 (UTC)
- Wait. Apparently I reacted to your comment too hastily, because I have just tried Design O in Minecraft: Java Edition version 1.12.2 and found it to actually work. Are you using Bedrock Edition or something like that? If that’s the case, you couldn’t get it to work because it requires Java Edition exclusive quasi-connectivity effect. — BabylonAS (talk | ru.Wiki Admin) 14:03, 2 June 2018 (UTC)
- Yes, I am using the Bedrock edition. The piston design I removed from the article, I removed after my initial comment almost 3 months ago didn't meet with any objection. I don't object to restoring it as long as it's clarified that it works only in the Java edition. For me, it quasi-worked. Sometimes, but not reliably. I hadn't noticed when I removed it that there was a lingering text description there.
- I also don't understand, what is the objection to using sticky pistons? Amatulic (talk) 23:00, 5 June 2018 (UTC)
- You need slime balls for sticky pistons. Sometimes you might have too much of them, sometimes you might not have them at all. — BabylonAS (talk | ru.Wiki Admin) 15:32, 7 June 2018 (UTC)
- @BabylonAS: Heh. Well, I'd say slime balls are no harder to come by than many other components if you're in survival mode. It's easier if you aren't playing solo (I play with my son in the same world, so we can gang up on slimes and other mobs if we want to). You're right though, you either have too may or not enough. I came up also with a more compact and efficient piston TFF design; see next section. Amatulic (talk) 20:12, 7 June 2018 (UTC)
- You need slime balls for sticky pistons. Sometimes you might have too much of them, sometimes you might not have them at all. — BabylonAS (talk | ru.Wiki Admin) 15:32, 7 June 2018 (UTC)
- Wait. Apparently I reacted to your comment too hastily, because I have just tried Design O in Minecraft: Java Edition version 1.12.2 and found it to actually work. Are you using Bedrock Edition or something like that? If that’s the case, you couldn’t get it to work because it requires Java Edition exclusive quasi-connectivity effect. — BabylonAS (talk | ru.Wiki Admin) 14:03, 2 June 2018 (UTC)
- You needed three sticky pistons, and my design only needs one (not counting one with the cauldron... how did you actually miss that? I used six pistons) but in both cases there’s a pulse limiter/generator, which may be replaced by another of its kind that doesn’t use a piston). While I’m grateful for your response, I’m not going to call this design an advance, however I do confess that it was a good try for a new (at least, for me) TFF concept. Also, something that I forgot to say yesterday. While you have removed the load-box template with Design O (which I call quasi-connectivity TFF, because it uses this trick), the textual description is still present. In my opinion, it is better to place this particular TFF under obsolete designs. Finally, the way you have placed replies is weird. — BabylonAS (talk | ru.Wiki Admin) 13:05, 2 June 2018 (UTC)
- Oh, my. Brilliant work, and makes efficient use of space... but the same efficiency as mine in terms of needing a total of 5 pistons in each design. Amatulic (talk) 17:27, 1 June 2018 (UTC)
- — BabylonAS (talk | ru.Wiki Admin) 17:04, 1 June 2018 (UTC)
More efficient bedrock piston design[]
In the article, I just added a section heading above the piston TFF designs, to separate them from "best in class". As far as I can tell they don't work in the Bedrock edition. The problem seems to be a difference in how to position repeaters when powering blocks. I'm not sure.
Anyway, with that in mind, I designed the T flip-flop below. It's only 6x6, uses 3 repeaters and 3 pistons (one is a sticky piston, for the pulse limiter).
Bedrock piston TFF
The T input can be north, south, or west of the sticky piston. This can be tiled in a cascade; you can put another copy directly to the right with the output going directly into the input of the next stage. I strung four of these together and made a 4-bit binary counter.
This works in the Bedrock edition. I'm curious how it works in the Java edition (which I don't have). Amatulic (talk) 20:12, 7 June 2018 (UTC)
- The design doesn’t use quasi-connectivity, as evident from the schematic, which means it is JE compliant. Nice work for a piston TFF, but locked repeaters (cf. LX designs) and droppers (cf. Grizdale’s design) make all piston TFFs seem obsolete. — BabylonAS (talk | ru.Wiki Admin) 14:17, 8 June 2018 (UTC)
- "Obsolote" depends on your motive. My objective was to make a mechanical contraption that's interesting and fun to look at. This would be one part of a larger contraption, say, a mechanical counting machine. I know TFFs can be made with non-moving components; those didn't interest me. Amatulic (talk) 15:23, 8 June 2018 (UTC)
- I've added it to the article in the Piston TFF section. Amatulic (talk) 06:19, 24 September 2018 (UTC)