PIOMinus the input link, this costs only one mechanism and draws 5 power.PiOMinus the input link, this costs only two mechanisms and draws 5 power.PABOMinus the input links, this costs only two mechanisms and draws 10 power.PA
BOMinus the input links, this costs only two mechanisms and draws a maximum of 10 power.PabOMinus the input links, this costs four mechanisms and draws 10 power.Pa
bOMinus the input links, this costs four mechanisms and draws a maximum of 10 power.PiOAgain: Both inputs are linked to the single gear (i).I eagerly await updates on this...In laymen's terms, preferably.
I'm not sure I CAN do layman's terms. Maybe have a look see at Wikipedia's Logic Gates (http://en.wikipedia.org/wiki/Logic_gate) article? The "gates" can be used for interesting goals, such as actual practical designs for traps or clocks or traps or automated obsidian makers... or traps... In case you're wondering the point of all this... I plan on making an artifact computer. I will probably be decorating my computer with images of Jong's Razorlength fortress...I eagerly await updates on this...In laymen's terms, preferably.
I still don't think I'm crazy enough to play this game properly.
QuoteI still don't think I'm crazy enough to play this game properly.
+1
Fuck it, sigged too. That was awesome.
A B Z C O
0 0 0 0 0
0 1 0 0 1
1 0 0 0 1
1 1 0 1 0
0 0 1 0 1
0 1 1 1 0
1 0 1 1 0
1 1 1 1 1PIOPAB
Z C
xCCPAB
ZxCOIPAB
ZxCI claim the title of first computer design in DF. ;)I'm well aware... it's the inspiration for my madness. :D
However, I am all for new and improved designs! The more the merrier! After all, I can scarcely claim a monopoly on all the good ideas!I'm afraid that's the major part of your design I don't understand. Specifically because I don't know what the difference between A0 and a0, etc. is in your diagrams. Are they a normal and a pre-triggered gear assembly, or are they simply the same links to normal gear assemblies? Also, from my research, I'm not sure if you're actually using a carry look ahead... it seems like there's not enough circuitry on the side of the most significant bit...
I still can't resist tempting you with the full details of my computer's design on post 1 on my thread. I'll just say here that the problems are not insurmountable! Even carry look ahead!
I recommend you test your output buffer/rotation sensor too. It is very important that it works reliably. I think your concept of a pressure plate that triggers when there is no water is quite interesting. From my experience, the free cycling pumps (that is, pumps where the output drains into the same body of water as the input) don't seem to conserve water, although I'm not sure why.Yeah, I do need to test it still, specifically in the aspect of ensuring that it never runs out of water. My expectation, however, is that if it is properly filled to 7/7 water before the pump turns on, it will act like the Dwarven Water Reactor does, and magically transfer the first tile of water from the plate and push it constantly up to the pump output tile. I'll be doing a step by step test of this, however, verifying that my assumption is indeed fact. If a 1/7 spot of water is ever visible on the pressure plate while the pump is active, it will not conserve water, though it may take a LONG time to lose it.
I audibly laughed when I saw that XOR gate, because it was the exact same design I tested in a logic test fort a week back. Heh.Yes, that is it's downfall, as my research into the 8-bit adder is proving. It makes it not the most useful design as anything but an input. Unfortunately, the gear resistor (I like that, btw) design is fidgety and depends on all of the pathways that all power takes through your system. I may look into using it at certain points of my adder to make it do an instant gear calculation, but I honestly don't like using gear resistors. (Load gear trains for people looking at the wiki article on mechanical logic)
The problem with it, though, is that it needs pressure plates or a lever to trigger it (I'm working on no water at all logic gates that work with power amounts and gear resistors). I don't know how much water you plan on using, but a single tile for each gate adds up.
Won't water pressure immediately drop the 7/7 water from the output square back on top of the pressure sensor?If my expectation is correct, that water is instantly sucked up by the pump. I will still need to test, but I believe it will only work when there is exactly 28 units of water in the system. 27 and it should act exactly like you expect, with water falling in then getting sucked up a step later. This is from my experience with the Dwarven Water Reactor design, which I'll duplicate for you.
XXXXX Bottom Level, 7/7 water in ~ tiles.
X~X~X
X~X~X
X~X~X
XX XX
XXX
XXXXX Top level, with 7/7 water magically staying
XW~WX at the north spots of the water wheels, and
XW^WX at the ~ tile. <% is a water pump, pumping
W%W north.
.
The floors under the water wheels are channeled out. You begin filling the channels with water. When the water level is at about 3-4/7, have a pump operator manually start the reactor. Continue filling it with water until the magic happens, 7/7 water in exactly nine tiles, the water wheel channels, and the north end of the reactor design's top level. I don't know why, but it works, and will never stop unless you block the pumps input tile with a floor or hatch. And when it stops it should spill 14 units of water. Which you'll then need to replace when you start it up again. This design produces 170 surplus power. Other variants can be made that will provide different amounts of power. A mini reactor with just one water wheel can produce 80 power perpetually. Larger versions add the mini reactor to one side or the other of the above design, and each extension of a pump and waterwheel will provide an additional 80 power. This is what I plan to power my computer with, though I believe I'm going to plan for a water cistern for all the water I'll be using to fill up these things. I'll still have to top them off after the fact, but it won't be so mind numbingly bothersome to get the first level of water in the things.
Now to update my wiki page, then figure out how to do look ahead carry, and maybe even have a single shot 8-bit adder unit with only a 100 step delay at most.Okay, from what I've seen, a Carry Look Ahead design needs a changed basic adder unit. I'm going to start the design here and see how far my insanity takes me. The adder that is needed is called a partial adder, and it supplies from the inputs of the two input numbers, a propagate value and a generate value. I'm not going to explain these... because I only slightly understand them. Suffice to say, this method works. The propagate value (which I will be diagramming as R, because P is power) is A XOR B. The generate value (G) is A AND B. So the partial adder looks like this:
rPABIn fact, anywhere we need the Propagate or Generate values, we can simply run power through the pre-toggled A XOR B gear or the normal AB gear train.PAB
rZCNote, that this diagram is from the side, and the floor is left between the A and Z gears to prevent a connection there, while the floors between P and r, and between B and C, are channeled away. Also note that this starts with the partial adder circuit, with the r gear rotated to underneath the power input.I'm afraid that's the major part of your design I don't understand. Specifically because I don't know what the difference between A0 and a0, etc. is in your diagrams. Are they a normal and a pre-triggered gear assembly, or are they simply the same links to normal gear assemblies? Also, from my research, I'm not sure if you're actually using a carry look ahead... it seems like there's not enough circuitry on the side of the most significant bit...
o=o=o=o=Cout
A A A a
B B b B
c C C C
P P P PWow... you post quickly...Nah, just had that second post ready to go, the forum futzed on me a bit, and I answered with the previous post before pasting the last post in and posting. I'll be studying your design now to see what I can make of it. It may end up that your ALU is the ALU to use, mechanically speaking. Hope you don't mind. ;)
EDIT: I also noticed a slight problem with the design for the rotation sensor. It should work as specified when filled to 7/7 water in all tiles; however, dwarfs filling a pond zone will only fill it up to 6/7 water*. This can be overcome by designating the pond zone on the level above and then carefully monitoring the amount of water that has been input until it is exactly full, then deleting the pond zone.Yes... I've seen this also. I'll have to take the dwarven insistence that 6/7 is full with pond orders into account in my build plans. Also, at work today (while dead and no business coming in, ugh) I had time to look at and truly understand Jong's solution. I am IMPRESSED. It works perfectly as the CLU in a two stage adder circuit. I tried making the adder one stage only, with direct outputs, but, unfortunately, this is impossible. A fluid Buffer is necessary per bit of operation. However, my concept of a triple input XOR gear is more elegant than the equivalent triple input XOR (needed for the final calculation of A + B + Carry) he uses. Simply, link those inputs to a single gear and have it drive the final output sensor. I also intend to design a specialized version of the Adder for use in my program counter circuitry, so that I don't have to co-opt the ALU for moving to the next instruction in memory.
*That is, they will keep dumping buckets of water into the hole until the tile directly below the hole is at 6/7 water. Thus, if the hole is an extra z-level above what you are actually filling, they will happily dump buckets into it forever, or until you tell them to stop.
PAb
BaO
P is power, A is non-toggled linked to input 1, B is non-toggled linked to input 2, a is pre-toggled linked to input 1, b is pre-toggled linked to input 2, and O is the output gear. Note that the A and a gears are out of phase, and thus, will never transfer power to each other.PAb P01 101
BaO 01O 010
PAb P00 100
BaO 11O 111
PAb P11 111
BaO 00O 001
PAb P10 110
BaO 10O 100
Two things:No need. In actual fact, contrary to the nature of electronics, Jong's design is perfect and works even better than the electronic equivalent. One can easily build an n-bit CLU from his design with minimal complexity. This is what threw me, as I was expecting to see a great amount of circuitry growing even more towards the MSB of the adder. With gear logic, more circuitry is not needed. And what's more important is that the result is a guaranteed two phase process. The first 100 steps accumulates the carry values all at once. The second 100 steps adds those values and the original AB inputs.
I've designed a 32-bit carry-lookahead adder in electric gates for a class (broken into 4-bit tiers for sanity), so if you want to look at my circuitry, I'll be happy to share it, but since there's no gate delay with gears and you figured out how to pass the signals, a ripple-carry adder will be just as good.
But, I'm skeptical of the operability of your pre-toggling. With doors and floodgates and bridges, pre-toggling has no effect; the first signal is ignored, and then they revert to their normal operation, which is why you need to use floodgates AND bridges in fluid logic designs, since their neutral states have opposite logical meanings.PTML never touches doors, floodgates, bridges, etc., unless you want the end result, say of a computer's GPIO block, to affect the status of such constructions. And when that happens you are using a truth value from the end result, not from halfway through the calculation. I think Shinziril may explain this better than I do, too.
Have you tested your designs physically? If they work, I'll be very excited, since it means we can feasibly create real circuits, particularly your adder is much more convenient than usual adders are.Yes, I have tested enough of these designs to know for a fact that they work, and using my methodology for tracing the truth value in a PTML circuit, anyone can verify that a design works, without ever needing to build it in game to be certain. This methodology is how I verified to myself that Jong's CLU circuitry does function exactly as needed.
If only there were a way to do all of this without linkages, though, or to have linkages triggered by power.
Oh, gods no. Its finals week, and now I'm stuck considering alternate design theories for basic mechanical logic. Cease your siren call, dwarven wrench!:D Sorry... I think?
*ZP
CC
PBAa PS
bB
Note that the C gears are undriven, and one is used as the input to a rotation sensor. Also note that the b and B gears have a second input, Z, the initial carry value. The final sum gear, S, is non-toggled and linked to the output of the rotation sensor connected to the corresponding C gear, the A input, the B input, and the Z input. It is, essentially a four input XOR gate. CC
PBAa PS
bB
CC
PBAa PS
bB
CC
PBAa PS
bB
CC
PBAa PS
bB
CC
PBAa PS
bB
CC
PBAa PS
bB
CC
PBAa PS
bB
CC
PBAa PS
bB
*ZP
There will be rotation sensors under one of every pair of C gears, and under each S gear. The sensors under the S gears provide the added value. Subtraction of B is enabled any time the Z input is on. This is done because in binary numbers, the negative of a number is the logical inverse plus one. Thus, any instruction set using this assembly needs to ensure that the opcode for adding uses a zero in a bit that the opcode for subtraction has a one at. This bit in the opcode can then be used to enable or disable subtraction from just one bit of the opcode. Jong's instruction set in the Razorlength computer has this feature, and mine will as well.||||||||||||||||||
|D|D|D|D|D|D|D|D|P
A|A|A|A|A|A|A|A|W|
||||||||||||||||||
__
P7654E
Where the numbers with lines over them are pre-toggled. The boolean equation for this would be, P AND 7 AND 6 AND NOT 5 AND NOT 4. Meaning the power would only transfer if we are addressing memory module number 12 of 16. This AND-chain would be needed on each incoming and outgoing bus line to a device. Come to think of it.... I may simply eliminate the address lines for the higher bits that address the correct module... nope. I'll have to. Now I'm just rambling aloud. I really should withdraw from society again...
Here's (http://mkv25.net/dfma/map-8582-woundrider) a link to my constructed version of that adder (I was working on it at the same time, and apparently came up with the same idea you did). It's not fully complete yet, and I think I managed to mess up the subtract-selector logic somehow (it seems to be giving me the bitwise inverse of the correct answer), but you can see how I set up the "support framework" around the logic and kept it as compact as possible. I also like that I managed to use a single powertrain to power the entire assembly.The biggest problem with DFMA maps is that you cannot tell what gear is linked to what, sometimes even when you use multi-colored gears. This makes such maps extremely difficult to decipher, even more so than my current method of diagramming.
If you're having trouble comprehending it due to the fact that all the gears look the same, take the diagram for Jong's carry logic unit and rotate it counterclockwise 90°. The top three rows of gears are oriented in exactly that pattern, and the bottom row is the triple-XOR combiner unit.
y y y y y y y y
X X X X X X X X
D+D+D+D+D+D+D+D+
X X X X X X X X
Y Y Y Y Y Y Y Y
y y y y y y y y
X X X X X X X X
+A+A+A+A+A+A+R+W
X X X X X X X X
Y Y Y Y Y Y Y Y
This view shows how the device selectors will work. X and Y inputs are the device selection inputs. Since the north side of the bus uses X and y gears, it will enable when the device selected is device 10, or 2. The south side of the bus uses X and Y gears, so it corresponds to device 11, or 3. The other two devices would use xY and xy gears to enable. I have dropped my idea for power supply via the data bus. Instead, I am doing what I needed to do, make separate Read and Write enable lines.
This view shows how the device selectors will work. X and Y inputs are the device selection inputs. Since the north side of the bus uses X and y gears, it will enable when the device selected is device 10, or 2. The south side of the bus uses X and Y gears, so it corresponds to device 11, or 3. The other two devices would use xY and xy gears to enable. I have dropped my idea for power supply via the data bus. Instead, I am doing what I needed to do, make separate Read and Write enable lines.
y y y y y y y y
X X X X X X X X
D+D+D+D+D+D+D D
X X X X X X X X
Y Y Y Y Y Y Y Y
y y y y y y
X X X X X X
+A+A+A+A+A+A+ +
X X X X X X
Y Y Y Y Y Y
D--EXYR
r
The floor between the Y gear (whether it is pre-toggled or not, based on the device selection) and the lower r gear is channeled out. On a positive Read signal, the R gear will engage and the r gear will disengage. When memory access for either write or read is disabled, the E signal, which controls the E gear, will be off. This will disengage the E gear and prevent writing to the memory bus when not needed.Cease your siren call, dwarven wrench!
The idea of linking multiple inputs to a single gear is really brilliant. You must direct me to the post where it was first mentioned.Thank Dorf3000 for this idea.
Anyway I was inspired to create a scheme for a single stage carry look ahead adder. The idea was that I could rearrange the gears in the sum circuit such that the C gears were at the root of the logic tree, or in other words closest to the power source. In this manner, the availability of the power supply can substitute for the triggered gear. So I could directly hook up the adder to the output of the carry logic circuit.Yes, I liked that part too...
However this necessitates the inclusion of an inverse carry logic circuit so that the inverse c gears can also be similarly substituted.
This was the result.
(Big Intimidating Image)
I used a colouring convention here to indicate the default state of the gear, which also indicates whether it is pretoggled or not. The light coloured gears are by default disengaged so they are the pretoggled ones.
I was reading your posts a little more carefully because I was wondering how your adder worked. Then I realized that the single gear labeled S was a triple input gear that substituted for the whole adder. I was pretty astounded.
So I was inspired once again to replace most of my adder's logic with double input gears. The amount of optimization is really staggering.Yes. Yes you have. Fewer gears and single stage adding is awesome. It means my computer architecture will be even safer. I plan on using a four phase cycle for it: Instruction fetch, Operand Fetch, Instruction Pointer Increment, then Execute. A single stage adder means all of the things I'm planning on pre-calculating while the timer is progressing through the fetch and increment stages will be completely guaranteed to be done by the execute phase is reached. More on this later on...
(Smaller Intimidating Image)
This modified circuit is identical in function to the previous one and has far fewer gears.
The gears marked A/B # are your pretoggled double input XOR gates. The gears marked AB # are the same but they are not pretoggled. I discovered that this configuration combines an AND gate and a NOR gate, which just so happens to be applied in the adder.
I believe I have really outdone myself this time.
EDIT: I found the post! Hmm.. I think in most cases it won't be necessary for the inputs to arrive at exactly the same moment. Here's something you can try to see if it breaks. You can link a lever multiple times to the same object before the first link job is completed. I tried linking a gear twice to the same lever to see what would happen. Pulling it didn't do anything as expected. You could try it with more linkings and see if the relationship holds up.Yeah, that was just me worried that the gear might not toggle if two signals are received at the exact same time step. I tested and verified that the gear toggles correctly, though I never thought to just use a doubly linked lever.
I noticed you intend to create a display device. 32x16 right?Yup. In a bit I'll show off the instruction set, the register set, the memory's address space, and my timing cycle.
My concern is that with only 8-bits you may have insufficient memory to store an image to display. I'm not entirely sure how your data scheme works but my computer was also 8-bits and it faces a number of constraints.My instructions will be 8 bits for the opcode, and some instructions will have an additional 8-bit operand. Specifically, memory addresses will be 8, not 5, bits. This gives me 256 addressable bytes, or 2048 bits of addressable memory. I do notplan on constructing every last one of these immediately. Thus I needed to have the bus designed and constructed so that I could, like real memory chips, "plug in" a new bank of memory when I decided to make more. It also means one of the bus devices will be a 512 bit monochrome display. Initially, I'm going to place the display in bank 11, and have only one bank of RAM at 00. That first bank of RAM will actually be slightly special, too, as it will also have a couple General Purpose Input bytes and a couple General Purpose Output bytes. GPI will be linkable to any lever or pressure plate anywhere. Such as a lever for controlling the computer. It'll be like a custom configurable keyboard, of sorts. The GPO will be used for general operation of hatches, bridges, doors, etc. I'm putting these in for completeness, more than any other reason. More on the structure later.
The 8-bit instruction size allowed for 8 instructions and 32 memory addresses. With 8-bits each, this comes to a grand total of 256 bits. A 32x16 display has 512 pixels! If you cut down the number of instructions to 4 and the addresses to 64, that comes to 512 bits of memory, at the cost of a truncated instruction set and having no room for programs!
Well I think your computer's architecture is rather unusual. Your bus design seems to incorporate separate paths for data and address/instructions I think, which doesn't fit into the Von Neumann model my computer used. Could you elaborate on your overall computer design?Yeah, real estate is going to be the big problem on this one. I'll be upping the z-levels between layers greatly in my world-gen when I actually move out of design and into building. I'll probably end up wanting a good 20 layers of solid rock available to play with. I'll also be turning off HFS for this. Now that I think about it, isolated from everything but dwarves would also be a good idea, though that usually results in untamed wilds, and knowing DF2010's military hit and miss bugginess, I want as little fighting to do as possible.
However adding even more memory is a big challenge. My design for memory cells is still a tremendous real estate hog. This is mainly because it uses pumps in its operation. I was thinking a fluid logic inspired system could potentially be more efficient, as it could use hatches or doors, which could take much less space. Its all about the management of the water sitting on the pressure plate, which is just a single tile.
Well I think your computer's architecture is rather unusual. Your bus design seems to incorporate separate paths for data and address/instructions I think, which doesn't fit into the Von Neumann model my computer used. Could you elaborate on your overall computer design?Oh yeah, the data bus. Forgot to elaborate on that. The bus will have data lines running to the memory banks, and to each register. The address lines only run to the memory banks, since only they need them. The RE and WE of the instruction set and basic timing are used by the control circuit to transfer data on the bus at each time step exactly as needed. The select which of each membor of the bus drives the data lines, and which one writes those driven data lines to their storage. Virtual Registers are on the bus, but do not respond to/have WE circuitry.
Here's a diagram for a fluid logic memory cell, using only doors.Interesting... Definitely nice for saving space on the memory bank floor. I'm just dead set on having a closed system, and that means no infinite water source. I WOULD be interested in any memory cell that conserves water, requires very little water, and takes up a minimum of space. I think my Hybrid Logic memory cell is the closest we can get to it, though.
XXXXXX
D1XX2D
XXXXXX
XXXXXX
D4XX3D
XXXXXX
XXDXXX
X#%>#X
X^XX%D
D%XXvX
X#<%#X
XXXDXX
1
4***P
| 2
3
The pressure plates numbered 1-4 on the bottom layer are set for 0-3 water. They connect to the gears labeled 1-4 on the top layer. These numbered gears are pre-toggled. After linking the pressure plates to the gears and to the timing circuitry of the computer itself, you turn off the power. Then fill the 1 pressure plate tile with water. 4/7 will do, but I like it to be full at 7/7. Turn the power back on and watch as your water visits each pressure plate for 100 steps each, round and round, til you turn off the power. Water is fully conserved in this setup. Note... the logic from the pressure plates is as follows:t 1 2 3 4
1 0 1 1 1
2 1 0 1 1
3 1 1 0 1
4 1 1 1 0
Which means logic that activates on the timer needs to flip the toggle state of any gear using the signal if it expects the signal to be active-on.
I see that your timing cycle is pretty short. You need to be careful to avoid conflicts in the various data transfers throughout the CPU, but I see that you have a large number of registers prepared for this. One problem with memory cells currently is that it takes 100 steps to write a zero to a non-empty memory cell.I am accounting for that in the registers. They should be ready by or before the cycle they are needed at.
And your timing circuit has some problems. One thing I discovered when building my computer's clock was that pumps do not turn off instantly when their power is cut. That is bad. Plus, because of the 100 step delay for pressure plates to reset, most of the time when your circuit is in operation, 2 pressure plates will be active. My clock used some null cells to hold the water while the active pressure plate reset.Actually, I constructed and tested my timing system. I have a save, and can provide a video if you want. However, just to state, there is never more than one pump on at a time, and the pumps only activate for about 6 steps total. The key to the timer is that the plates are on when empty and the gears controlling the pumps are pre-toggled to invert this signal. This is the reverse logic that most people expect, however, it is easily accounted for by pre-toggling whatever the signal coming from a stage goes to. Gears are beautiful things. To give a run down of how it works, I'll take it step by step.
I think I'll figure out how to upload my timer video. Be right back.Hmmm... Doesn't seem to like my video. Is DFMA not compatible with DF2010 movies?
Though it would massively increase space and (in a number of respects) material usage, you could probably build an ultra-high-response computer using waterwheels for triggers instead of pressure plates. I'm currently working on basic designs. Due to the large space of the individual gates and difficulty in containing fluid, I'm not 100% sure if it's even possible, but I'm looking into it atm.:o
Oh, one last thing: For pre-triggering gears, you can link ALL of them to a single lever to flip, and save N-1 mechanisms for constructing all the temporary levers.
Even if you didn't have enough memory to store an entire picture for the display, you could just generate one procedurally! Dwarven fractals, anyone?Not sure how that would work. I know I could limit the display to a text only display, but that would require a memory bank for the text font. That bank may, however, not be needed within the Accessible RAM... instead it could just be used by the display circuitry. Then instead of 32x16, it would be 4x2 or 8x1, or whatever, and an 8x8 block of pixels could be flipped in one instruction instead of 8. Considering how fast things run, this may even be a better choice. Since the "video" out is far off in the future for me, I'll be giving this some thought.
I did think that the gear resistor designs on the wiki were ridiculous, but I didn't actually realize you could do this. It's carved in stone in my head that levers don't toggle, I guess. Thank Toady that gears are the exception to this rule, yes? :DYup. One of the coolest things about gears is the fact that, with the limitation that a gear can't directly toggle another gear, you can build any circuit you can imagine.
Now the real biggest problem here is a practical application for computers in DF. It's cool and all but it's a hell of a lot of work for no real end. Then again, it is a sandbox game...I've thought about this over and over again, and all I come up with is a devious and insidious trap system that constantly keeps victims running for the exit that changes over and over again. An evil maze that changes randomly, but always has an exit. Pit the victim and watch them dance in misery. Other than that... yeah, it's probably just a big bragging rights parade. :D
By the way, I couldn't get heads or tails from your data bus diagrams. It would be advisable to always label such charts whether they are top-down or side-view.True. But then, my data bus design isn't 100% set in stone, so to speak. I'm still figuring out the kinks and timing and delays and other irritations.
Also, using the teletype (tt) tags instead of code you can include underlines to denote floors while maintaining a monospace font (you can also use colors!):Okay.... Now that I LIKE. I'll have to keep that in mind. Is there an easy equivalent for the Wiki?
(side view)
PAB
rZC
Oh, one last thing: For pre-triggering gears, you can link ALL of them to a single lever to flip, and save N-1 mechanisms for constructing all the temporary levers.Yup. And you only have to flip it once. The only thing that matters is that the gear is pre-toggled, not how exactly it is done. You could, if you were nutty enough, do it with a pressure plate.
Okay.... Now that I LIKE. I'll have to keep that in mind. Is there an easy equivalent for the Wiki?
I implemented an 8-bit adder-subtractor using Jong's logic design (http://dffd.wimbli.com/file.php?id=2282). It works very nicely.
This is a post from 7 years ago, that user is no longer active. Y U Revive?