Binary Counter with Logical Left Shift

NanoPi

Steampunker
I made a binary counter out of flip-flops chained together
counter_b.png

counter_w.png

and then tried to add a reset mechanism but ended up with a Logical Left Shift instead.

counter_shl_b.png

counter_shl_w.png



Video

https://gfycat.com/HideousSpeedyAmericanratsnake

 
This was interesting; it inspired me to figure out how to make the originally-intended device: a resettable binary counter. Had a lot of trouble with the design until I added AND gate diodes for the reset signal:

Capture 2016-05-28 00_01_10.png

Capture 2016-05-28 00_01_16.png


As far as I can tell, doing it without the diodes would require spreading the gates out more to give you enough room to not have all four colors of wire adjacent to the top row of faulty lamps.
 
Dang it MageKing17, you beat me too it. I tab back and refresh and someone has the solution ;(

Well here is what I came up with (your design is more elegant):
NW3vRSp.png

tgOODcG.png


But as a side note, the entire reset mechanism can be much simpler (and closer to the OP's original design) if you just space things out a little:
Y49LmXR.png

yYIa01L.png

[doublepost=1464423360,1464420782][/doublepost]I kept toying around with the design and I came up with a simple way of including both the reset AND the left bit shift:
xFbI0gH.png

CoLKDnQ.png


Here it is in action!
 
and then tried to add a reset mechanism but ended up with a Logical Left Shift instead.
Which is precisely what happened to me when I was fiddling with the setup the other day! :) These Faulty Logic Lamp Flip-Flips (FLLFFs, right?) seem to almost have a mystical desire to do binary computing opperations. I hid my FLLFF shifter and reset builds here, at the bottom of my thread on flip-flops.

Note that mine run the wrong direction (towards the left), because I'm silly like that.:confused: Most significant bit should be left-most, of course (the other way around). But I gave my rows a little more vertical space, and kept them in line, so it's visually easier to see what's going on and also extend the lines out vertically to more devices, etc:

Note a few things:
  • For count to indicate correctly on torches, the torches connected to each counter stage's lamp must be in the on state when the FLLFF input lamps are darker looking. This seemed backwards to me, but I guess that darker indicates actuated, which would be associated with switching state for the first time: off to on.
  • Because of the above point, I found that the a (simple) reset always set the count to 11111 (all torches on), so I needed to add +1 after the reset action. (If the reset line had inverted logic state, that's when it becomes a shifter function instead...) I did that using a single self-feedback and gate plugged into the first stage of the counter (but in the reset row of gates). I took the idea from @DicemanX's AND gate reset mechanism.
  • I found an invert all bits function, by simply sending input to all the faulty lamps of the counter at the same time. (AKA, compliment or NOT function.) I needed to add an extra buffer gate to the input (1s) stage to invert this layer.
  • You can count in 1s, but also in 2s, 4s, 8s, etc, by sending input to that stage of the counter directly. So it's probably more appropriate to call this thing an 'accumulator', since you add to it any other binary number, just by transferring input states to all the appropriate positions at once, and have it ripple through. I could be wrong, in that I'm not sure the gates will always be able to handle this, given there build in protection coding. (Will they sometimes smoke and fail?)
Anyway, here's mine demonstrated doing a subtraction as an addition to an inverted number (and then reverting after, so the second number entered is subtracted from the first):

So anyway. Keep up the good work/play. I'm very interested to see how multiplication will be done most simply. It should just be shifted adding, but I think might require a 3rd 'register' to perform it easily in a setup like these.

Shifting is also one of the two parts of binary to binary coded decimal conversion. The other part (for the double dabble conversion method) being: +3 if the 4th bit of a BCD digit is st to 1. BCD convertors are all that is currently lacking, now, to interface these counters/calculators to decimal 7-seg displays. It may well be that this algorithm (which Diceman previously implemented with hoiktronics) is not the most appropriate, now, with these gates. I think there are other (more directly reversible) methods and also ways of doing calculations natively with BCD, without converting back and forth to straight binary. But that's beyond my knoweledge, so I'm waiting to be dazzled. ;)
 
  • Because of the above point, I found that the a (simple) reset always set the count to 11111 (all torches on), so I needed to add +1 after the reset action. (If the reset line had inverted logic state, that's when it becomes a shifter function instead...) I did that using a single self-feedback and gate plugged into the first stage of the counter (but in the reset row of gates). I took the idea from @DicemanX's AND gate reset mechanism.
Uh, my design here does not; it resets to all torches off, and doesn't do it by setting to all 1s and performing an additional +1 at the end.
 
Uh, my design here does not; it resets to all torches off
Although it uses a second stage of (AND gate) diodes in the reset...? I don't know for sure the best way to do these things, but with only a single additional line of gates (FLLFFs), the design I mentioned, with the "set + 1" functionality, was the best I could find.

Could you show us a Gif of yours? Particularly if if (still) contradicts what I'm saying. :)
 
Although it uses a second stage of (AND gate) diodes in the reset...?
Only because I ran out of wire colors... although I think I just realized a way to do without. I'll have to rebuild the thing and take another set of snapshots.
Could you show us a Gif of yours? Particularly if if (still) contradicts what I'm saying. :)
I don't have any convenient screen-capturing technology outside of the in-game camera mode; I have FRAPS, but no software to convert that to GIF format.

However, it should be noted that @crawlr's version here, with both reset and shift functionality (and includes a GIF of it in action at the end), resets in exactly the same way and doesn't include AND gate diodes or require a +1 stage to the reset.

Quite simply: if your reset resets to all 1s, you've got your reset lamps toggled backwards.
 
However, it should be noted that @crawlr's version here, with both reset and shift functionality (and includes a GIF of it in action at the end), resets in exactly the same way and doesn't include AND gate diodes or require a +1 stage to the reset.

That's correct, and above the full version is one that just includes a reset switch which may be easier to look at and figure out whats going on with that specific step.
 
if your reset resets to all 1s, you've got your reset lamps toggled backwards.
Nope, this was why I made a point of spelling out:
For count to indicate correctly on torches, the torches connected to each counter stage's lamp must be in the on state when the FLLFF input lamps are darker looking.
There is only one way around to have them to count with 1 = "torch on", 0 = "torch off". If you simply switch the torch's states then 1 = torch off, so you'd be counting with un-illuminated bits.

....Ok, I find that wiring setup a little harder to parse, largely cos it's not mine:p, but also because of of the curved wire paths - I like nice straight inter-connects. :)

Anyway, the difference between our setups is that @crawlr's doubles up on interconnect wires, between each bit of the accumulator and of the reset mechanism. 1 set connects to both the enable/disable (regular) lamp and the other to the input (faulty lamp itself) and the regular lamp. Because I only used 1 set of interconnectors, they are connected to both inputs. So when my reset fires it also increments all the bits by one. Hence ending up set to 11111, and needing an extra count adding.

My wiring is perhaps less logical, but there's a clear advantage in wire colour use, so might prove to be preferable in future applications, provided the additional gate steps don't cause technical problems (or too much confusion).
 
Nope, this was why I made a point of spelling out:
There is only one way around to have them to count with 1 = "torch on", 0 = "torch off". If you simply switch the torch's states then 1 = torch off, so you'd be counting with un-illuminated bits.
Wrong lamps; your binary counter's lamps aren't backwards, your reset gates' lamps are backwards.

EDIT:
I think I just realized a way to do without. I'll have to rebuild the thing and take another set of snapshots.
And here we are: the compact resettable binary counter that doesn't rely on AND gate diodes.

Capture 2016-05-28 05_45_38.png

Capture 2016-05-28 05_45_44.png
 
Last edited:
Wrong lamps; your binary counter's lamps aren't backwards, your reset gates' lamps are backwards.
My counter's lamps are fine yes (they have to be dark when torch is lit, as I said). I also explained that, with my counter's wiring, it's not possible to have the reset lamps the 'correct' way around because it creates a shifter function instead. This is because the output from the reset's faulty logic lamp gates are connected to the lamps and the input of the counter's FLLFF gates.

What you appear to have made, here, is a functional replica of @crawlr's design which has 2 sets of wiring so that the output from the reset gates only triggers the torches and the regular lamps of the counter's gates:
Yes, it's a good way of building a counter with reset such that you don't need an additional signal to do a direct to 0 reset. But I'd like to see if either setup are equally as suited to use in a more involved device, with additional connections that might require isolated wire colours.
 
My counter's lamps are fine yes (they have to be dark when torch is lit, as I said). I also explained that, with my counter's wiring, it's not possible to have the reset lamps the 'correct' way around because it creates a shifter function instead. This is because the output from the reset's faulty logic lamp gates are connected to the lamps and the input of the counter's FLLFF gates.
If inverting the lamps results in a shifter, then how are they resetting at all? Either they target only those bits that need reset, or they don't; if they do, then inverting won't change their targeted nature, and if they don't, then it's not functioning as a reset in the first place.
 
inverting the lamps results in a shifter
...because in my wiring the output from the reset and/or shifter rows also connects to the (faulty lamp) input on each of the (flip-flop) stages of the counter. If the lamps are set in this (the reset/shift) row such that their gates trigger when the corresponding bit (in the counter) = 1 (i.e. torch on), it will set the input lamp on the filp-flop from off to on (turning it's torch off, like a reset) but also trigger the faulty lamp input, thus toggling the next flip-flop to on (if it was off). Thus shifting the the on bits upwards, instead of just resetting.

To go a step further in showing the faulty lamp gate's flexibility, here's a counter with a reset line integrated and an (accidental) shifter line, all with just 1 lamp randomisers:
ElderlyEquatorialAfricanwilddog.gif
 
Back
Top Bottom