Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jjdorf]

I have been hard at work (in a lazy sort of way), designing a new "ideology" for mechanical logic.  Inspired by Jong's Computer (here), and with a slight refinement to one of my gates by Dorf3000 (Thanks!), The result is, I believe, a very elegant, and more importantly, water conserving logic system.  It can often use a minimum of power as well, and can be easier to build than the equivalent fluid logic gates; generally fewer mechanisms, less linking, few extra parts such as bridges, floodgates, etc., allowing more of the system to be built by dedicated mechanics dwarves, and only requiring a minimum of other construction labors.  The full Wiki page I am using as a scratchpad for my ideas is here.

The first design ideology to consider is the following: All input signals to a gear are linked to the gear in logical true value.  This means any levers linked should be flipped on by default.  It also means that pressure plates from hybrid mechano-fluid gates are designed to be active on 0-3 water.

The second design ideology is that certain gears are pre-toggled in order to change the semantics of their logic.  This is the key to not requiring any excess power load, such as used by these logic gates.  A gear is pre-toggled by constructing a lever, linking it to the gear, flipping the lever, then dismantling the lever.  A pre-toggled gear costs two mechanisms to build (not counting input links).

The third design ideology is that power is truly used as just power, and there are no requirements for calculating how much power the system will need, except for knowing the maximum power draw in a circuit.  No basic mechanical logical gate draws more than 10 power for the functional parts, though power train not linked to a lever or pressure plate may draw more.

At this point, only two basic fluid using gates are part of this ideology.  The first, which is commonly called a rotation sensor, I call a Fluid Logic Buffer (FL Buffer).  It's purpose is simple: take an incoming signal from the result of a mechanical power train, including logical gates, and convert that into a signal from a pressure plate.  This outgoing signal increases the "fan-out" of the signal, by being capable of linking to very many other gears.

The second fluid using gate is a Memory cell, designed as a D-Type flip flop.  What this means is fairly simple.  When the cells has power, it's pressure plate takes on the same signal as the incoming signal, the Data signal.  If the data signal changes while the cell has power, the cell will change.  Since a pressure plate is used, there is a latency of 100 steps when the data signal drops to zero.  While the power is off, the cell retains the same value as the last Data value while it was on.  Further changes at this time to the data signal will not cause the cell to change.

Details on these gates and the design can be found at my wiki page

Now, however, comes the more interesting part (IMHO).  The mechanical logic gates.  Some will be familiar, others will be new to some of you.  Conventions used in gate diagrams:  Power gear or train is identified with P.  Output gear or train is identified with O.  Input signals are I, A, B, i, a, or b.  An input signal that is lower case must be pre-triggered.

ML Buffer
This is a mechanical buffer.  It takes an incoming signal (Such as from an FL Buffer), a power supply, and outputs power - 5 if the signal is on.

Code: [Select]

PIOMinus the input link, this costs only one mechanism and draws 5 power.

ML Inverter (NOT)
This is much like the buffer, except the signal is inverted.  This is done by pre-toggling the input gear.

Code: [Select]

PiOMinus the input link, this costs only two mechanisms and draws 5 power.

ML AND Gate
This is the same standard gate as most will be used to.  No pre-toggled gears in this one.  It has two input gears, A and B.

Code: [Select]

PABOMinus the input links, this costs only two mechanisms and draws 10 power.

ML OR Gate
Another of the gates most will be used to seeing.  I generally intend to build these vertically on two floors.

Code: [Select]

PA
BOMinus the input links, this costs only two mechanisms and draws a maximum of 10 power.

ML NOR Gate
This is where the pre-toggling makes things more interesting.  Due to the nature of logic gates, inverting the inputs to an AND gate results in a NOR gate.  This is done by pre-toggling the inputs.

Code: [Select]

PabOMinus the input links, this costs four mechanisms and draws 10 power.

ML NAND Gate
Like the NOR gate, inverting an OR gate's inputs results in a NAND gate, logically speaking.  Again, this is done with pre-toggling.

Code: [Select]

Pa
bOMinus the input links, this costs four mechanisms and draws a maximum of 10 power.

ML XOR Gate
This gate is deceptively simply, yet quite powerful.  It combines two inputs onto a single gear, which is pre-toggled.  When both inputs are on, or both are off, the gear will be disengaged.  Only when one of the two inputs is on will the gear engage.  This results in an extremely elegant XOR gate.  I cannot take credit for this one.  Thanks, Dorf3000!

Code: [Select]

PiOAgain: Both inputs are linked to the single gear (i).
Minus the input links, this costs two mechanisms and draws 5 power.

I am continuing some research, looking for ways to further my withdrawal from society... I may have taken on a secretive mood.  Or perhaps a fey mood, considering I'm not being particularly secretive (though I am drawing lots of sketches, so to speak).  Has the title of first computer design in DF2010 been claimed yet?

[DarthCloakedDwarf]

Um...

Er...

I'm sure that post would be profound... if only I could understand the tiniest part of it.

[Daenyth]

I eagerly await updates on this...

[DarthCloakedDwarf]

I eagerly await updates on this...

In laymen's terms, preferably.

[furrot]

I still don't think I'm crazy enough to play this game properly.

[jjdorf]

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 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...

And if you're going to ask me what the point of the computer is... I'm afraid there really isn't one.  Kind of like the point behind a dorf making an artifact lead flask.  One makes it to point at it and say they made that.  Not because they seriously expect a person to drink booze from a flask made of poisonous material.  Not because they seriously expect a dorfputer to be fast enough to deal with any important calculations in time to do anything useful.  Might be interesting to see if I could program a pong game in it and get dorfs to play it.  But that is in the far future of this lovely artifact computer.

Now I'm off to actually work on a proper data bus architecture...

I know, I know... layman's terms... 

[Shiv]

I still don't think I'm crazy enough to play this game properly.

+1

Fuck it, sigged too.  That was awesome.

[jjdorf]

I still don't think I'm crazy enough to play this game properly.

+1

Fuck it, sigged too.  That was awesome.

 

Okay... so my next bit to tackle, I think, is going to be designing a basic full 1-bit adder in mechanical gears, using as few mechanisms and axles as possible.

First the truth table for addition with A, B input numbers, a Carry input (Z), and two outputs, Carry out (C) and Result Output (O).

Code: [Select]

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 1
With a little research, this equates to the following:

O = A XOR B XOR Z
C = (A AND B) OR (Z AND (A XOR B))

The gear assembly to produce O is remarkably simple, and uses a three input XOR gate.

Code: [Select]

PIO
A, B, and Z signals are all linked to the input gear I, which, unlike the two input XOR Gate, is not pre-toggled.  Gear I will be engaged and transferring power from P to O whenever one or three, but not two, of the inputs are true.  This matches the truth table above for O.  Like all other single gear assemblies, this only takes 5 power to run, excluding the power and output trains.

The gear assembly for C is a bit more complex, but still quite doable.

Code: [Select]

PAB
Z C
xCC
A, B, and Z gears are linked solely to their respective inputs.  The gear labeled x is a pre-toggled XOR gate linked to A and B.  The gears marked C provide the output for the Carry output function.  This would require 30 power to run, excluding power and output trains.  However, if built on two levels and properly channeled, this gear train can use two less gears and can be built only one tile wide.  From the side:

Code: [Select]

PAB
ZxC
The tiles that P and B gears rest on need to be channeled to transfer power, but there needs to be a floor between the A and x gears.  The end result is that this gear train only costs 20 power to run, excluding the cost of the power train and output train.

Combined, and still from the side, this can easily result in the following gear train for a complete full carry adder, which will only use 25 power, excluding power and output trains, and which will be exactly one tile wide, five tiles long, and two tiles high:

Code: [Select]

OIPAB
  ZxC
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.

[Jong]

I claim the title of first computer design in DF. 

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 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.

[jjdorf]

I claim the title of first computer design in DF. 

I'm well aware... it's the inspiration for my madness. 

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 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'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 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.

So many things to test...

[Rotten]

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.
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.

[tweinst]

Won't water pressure immediately drop the 7/7 water from the output square back on top of the pressure sensor?

[jjdorf]

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.
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.

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)

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.

Code: [Select]

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.

[jjdorf]

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:

Code: [Select]

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.
Now for the CLU (Carry Look Ahead Unit).  A carry for a given bit position _x is defined as follows:
C_x=G_x-1 OR (R_x-1 AND C_x-1)
Gear assemblies for OR values and AND values make this calculation simple enough.  I will diagram C_x as a gear labeled C, and C_x-1 as a gear labeled Z.

Code: [Select]

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.
The difficulty now comes in the form of that Z gear, which must reflect all the same logic but for the previous bit.  And this is where I am hung up.  One cannot simply connect each stage via axle, as that merely creates an AND relationship.  There are two options: reduplicate the circuitry at the Z location, spreading each additional stage out to account for the new circuitry; or, use a rotation sensor on the end of each stage.  The rotation sensor is needed anyway for the final calculation, but it will introduce a ripple effect, causing the same slow response that a basic ripple adder would cause, making this whole concept pointless.

I will have to continue researching this...  Jong... Any help?

[Jong]

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...

Hmm.. I think my convention is opposite to yours. The capital letter labelled gears are by default off, which means they are pretoggled in your terminology. Most of the gears in my computer have been pretoggled as shown by the massive preponderance of orthoclase gears in my build.

As for my carry circuit, I worked out a scheme to recycle the output of the previous (less significant) bit's carry calculation.

The blank gears in the middle are the output collecters to power C1 but they also double up as an input into the next carry calculation.

I worked out this method by using Boolean Algebra to simplify the more complex systems used in real life carry look ahead systems. I found that the basic logic is ridiculously simple.

Essentially, a carry signal is only produced in 4 cases: when A and B are 1, when A and B and the previous carry are 1, when either A or B is 1 and the previous carry is 1. My final design is optimized to occupy the minimum amount of space, so the logic pathways aren't immediately obvious but this system is equivalent.

Code: [Select]

o=o=o=o=Cout
A A A a
B B b B
c C C C
P P P P
In this manner I found I could ditch all the propagate and generate signals that need to be calculated.

As for optimization, the first two logic pathways are redundant and I reduced them to simply A AND B. I also only need 1 C and P for the remaining two pathways and I can redistribute the power after that. Also, oppositely toggled gears of the same input can be placed next to each other without fear of power transmission.

The OR logic cannot be compacted down however, because I chose to directly hook the output power of the previous carry circuit as the input power supply of the subsequent carry circuit. I need to retain the lower case gears to avoid reverse power transmission, if A and B are both active.

Directly hooking the output of the previous carry circuit to the next carry circuit removes the need for any rippling sort of effect, so this system generates all the carry bits instantaneously and simultaneously.

Wow... you post quickly, hang on while I read your new posts....
Ok, I think I answered your question.