Print

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

[Flaede]

thankyouthankyou! useful diagrams!
so much of the dwarfputer talk has been theoretical. And therefore jargon filled in ways I am not equipped to follow. I know why this is, and am not bothered by it, more bothered by my own limitations. Thank you for giving me something to work with. Plans I can handle.

Kanddak - if you wanted something more predicatble than freezing, you could try coulting time from the water resulting from waves from the ocean. They're slightly more regular, and could work easier for smaller time units.


EDIT: Q - why 0-5 and not 0-7 triggers? I'm worried I spoke too soon about following plans...

[Kanddak]

EDIT: Q - why 0-5 and not 0-7 triggers? I'm worried I spoke too soon about following plans...

A 0-7-triggered plate would be triggered all the time and therefore useless.

I used 6-7 triggered plates on the adders. This meant that when water pathing was closed off to a certain plate by a change in the state of the adder, it would only have to drain down to 5 before shutting off. This doesn't normally cause a delay when water pathing opens to a given plate, because the water coming in is under pressure and fills up to 7s very quickly.
If I'd used, say, a 1-7 plate, the plates wouldn't clear until they drained and evaporated completely. No good.
A (2-4)-7 might also be alternately triggered and released during the draining process when I've shut off the water into the system and am allowing it to drain out of everything (no longer under pressure), which is also undesirable.

I said 0-5 triggers for the display controller with the idea of using bridges for the display segments. When a plate becomes triggered it sends an "open" signal and when it becomes untriggered it sends a "close" signal; a 0-5 trigger plate will be triggered in air, but when submerged in 7/7 water would untrigger, and send a "close" signal to the retracting bridge which would then extend. When blocked, and drained to 5 or lower, the plate would trigger again and retract the bridge.
The inverted case of the unusable 1-7 plate I used in contrast to the 6-7 plate would be a 0-0 plate.

If you're using gear assemblies, it doesn't actually matter whether you use a 0-5 or 6-7 plate, because gear assemblies just toggle their state when they receive either signal. You have to link them to an initialization lever to make sure they start in the state you want them in.

You could even use a 0-5 and a 6-7 plate together in each segment, if your display design called for using a 6-7 plate to open a hatch to pour water into a channel when a segment is on, and then having a 0-5 plate linked to a hatch that would let it drain back out.
If you wanted to pump water into a channel when a segment's on and pump it out when it's empty, you would use either sort of plate, and link it to the gears that transfer power to both pumps, but link the gear to the flood pump to some throwaway lever and then pull that lever to disengage it until the plate's submerged and changes state.

[Martin]

BTW, the only appropriate way of doing a 7-seg in DF would be obsidian hatch covers over magma.

Just sayin'

[crazycarlt]

This is awesome. If I weren't focusing on my dwarflog now I would totally do this.

[Kanddak]

Well, I worked out how I'd set the inputs to a display controller.

Spoiler (click to show/hide)

Of course that's just the topology of the thing. Only one byte could be that clean, if 4 bits go south and 4 bits go south with their axles. The rest will have to have longer axles, or be on different z-levels, or otherwise be moved around.

I haven't actually tested that pump->plate->diagonal drain design to see if it behaves like it should.

About that second design:
I started designating the digging for display controllers in Numberabbey to see how they'd fit, and the answer was "only barely if at all". There's no way I could get twelve on that small map with my z-levels laid out the way they are. But I could get four.
So there was just a little mechanical logic involved in designing a way to make a display be controlled by either set of input levers or by the result gears. (Of course, if the inputs had their own dedicated displays, the input levers could link to display-controllers directly instead of having to use these kinds of transmissions)
Much less effort than building three sets of displays, but doing each bit that way would still require a lot of linkages to the control levers, some careful spatial planning, and almost certainly multiple z-levels. It'll also use a lot of power.

Just for reference, I've also put the schematics for the adders into the same format:

Spoiler (click to show/hide)

Edit: Ok, here's how I'd lay out the display switching for a 16-bit adder if I were truly insane:
http://i576.photobucket.com/albums/ss208/kanddak/display-multiplexer.png
There's a 1-tile north-south axle missing from the top center of that plan that I'm not going to bother to put back in.
That could be done upside-down depending on fort layout, with +3 becoming -1 (it has room for the vertical axles) and the axle housing removed from the reservoir on +1/-3. Many of the gears need to have floors under them to prevent them from contacting gears on another level.

Parts list:

Spoiler (click to show/hide)

4 blocks of each color (for pumps)
subtotal 16 blocks
16 yellow mechanisms (power transfer from result gears)
16 red mechanisms
16 blue mechanisms
49 green mechanisms (inc. lever)
49 cyan mechanisms (inc. lever)
subtotal 146 colored mechanisms
113 neutral mechanisms (distribution gear assemblies)
   optionally 32 of these a different color for transfer-between-z-levels gears
64 neutral mechanisms (links from input levers to red/blue gears)
192 neutral mechanisms (links from display-control levers to green/cyan gears)
193 neutral mechanisms (1 initialization lever + 96 links to gears starting disengaged)
subtotal 562 neutral mechanisms
subtotal 708 mechanisms
total 724 stones


16 logs for vertical axles carrying power from result gears
44 logs for level-2 axles
16 logs for axles inside display-control units
53 logs for level-3 distribution network
total 129 logs

maximum power consumption:
16 pumps * 10 = 160
144 colored gears * 5 = 720
113 neutral gears * 5 = 565
129 logs of axles / 3 = 43
total maximum power: 1488
Axles may use slightly less; when I was counting them I forgot to keep their lengths after I'd worked out their log costs and I'm not doing it again
And obviously not all gears are logically able to be engaged at the same time.

[LegoLord]

BTW, the only appropriate way of doing a 7-seg in DF would be obsidian hatch covers over magma.

Just sayin'

That would be slow.  And Obsidian is not magma proof.

Oh, wait, I get it.  Dwarfy

[Flaede]

Anyone got a way to quick-fix this into a "click counter" ? I tried and failed. I want to use it to "count up" every time it gets triggered from a wave. I got as far as the time-delayed release for making sure it was just ONE 'click' per wave... and got stuck... I fail at dwarfputing.

[Kanddak]

Anyone got a way to quick-fix this into a "click counter" ? I tried and failed. I want to use it to "count up" every time it gets triggered from a wave. I got as far as the time-delayed release for making sure it was just ONE 'click' per wave... and got stuck... I fail at dwarfputing.

That's totally different logic.
Here's a theoretical design for a 1-bit counter:

Spoiler (click to show/hide)

It should be pretty easy to string a bunch of those together to make an arbitrarily large counter.
For extra points, make the last one drain into your fort, so when the counter's value overflows, it overflows.

I've been working on a proof-of-concept for the 7-segment display controller design, and should have a fort & demonstration movie up within a week or so. This means I don't have time to test that counter design, so I'd be interested to see what anyone else does with it.
I suggest operating it with a plate triggered by hostiles, at the bottom of a shaft, in a room full of dogs. Then you could count how many goblins you'd thrown to your dogs.

[Flaede]

Anyone got a way to quick-fix this into a "click counter" ? I tried and failed. I want to use it to "count up" every time it gets triggered from a wave. I got as far as the time-delayed release for making sure it was just ONE 'click' per wave... and got stuck... I fail at dwarfputing.

That's totally different logic.
Here's a theoretical design for a 1-bit counter:

Spoiler (click to show/hide)

It should be pretty easy to string a bunch of those together to make an arbitrarily large counter.
For extra points, make the last one drain into your fort, so when the counter's value overflows, it overflows.

Thank you so much, Kanddak! I'll get to testing shortly!

I was hoping to work in a reset, instead of an overflow. Then I can have the counter just log x-number of ticks. where x=1 month. or 1 season. depending on what is realistic. Then I can tie it to a second set of counters (...oh joy) which would have the result of converting it to a useful number. With enough of these "layers" I can begin to build a clock/orrery. Also - was hoping to figure out ways/reasons to use this ever-changing number in your adding machine. Like say, pull levers to set the initial year, then use the orrery to count up from that once you turn it on.     Or to set how long you want the back gate automatically open/closed/waiting before switch to the front gate.


The wave per month/season/year number crunching comes first, however. Mechanical Industry, Strike THe Earth!

[crazycarlt]

I have a question.
Why not use mechanical logic for the adders?

[Kanddak]

I have a question.
Why not use mechanical logic for the adders?

Short version: Because it'd be a colossal pain in the ass.

Long version: I dunno. Try designing a fully mechanical adder, and tell us if you run into any insurmountable problems.
As far as I can tell, finding a way to pass carries would be the main difficulty.
I can think of two ways to do it.
One would have the adder for each bit produce only a sum, and put its carry logic in the next bit. This would mean that the control levers for each bit would control gears in every more-significant bit and your most-significant bit would look like a russian doll with the logic of every other bit nested into it.
Example:

Spoiler (click to show/hide)

There's a certain something to that kind of fractal adder setup, but it starts to make my head hurt just to design it (I originally meant to show four bits).
Doable, but excruciatingly impractical, extremely mechanism-heavy, and you're going to need a metric assload of logs to make the waterwheels to run it. And god help you if you link a lever to the wrong gear.

The other would be to use a mechanical analog of my fluid design, with the carry output connected to a pump-and-plate that flip the gears for the next bit. But I figure if you're going to dig the giant water collection/distribution/drainage system to do that, you may as well just use that for your logic and skip the giant mechanical system.
Example:

Spoiler (click to show/hide)

I think the latter's kind of silly -- going mechanical for most of it and then ending up using fluids anyway at the end because there are no triggers that act based on whether they're powered -- but the former would be a lot of fun to see in eight or more bits, just for the sheer dwarven insanity of it. Good luck and godspeed if you're going to try it... and I hope you find a good way to organize it when you have more triggers acting in one adder than there are colors. Maybe open the design up enough to draw labels with colored floor tiles, at the expense of more axles.

Work continues on the 7-seg demo. It took one year to establish a fort and build the parts and infrastructure, and another year to install and link everything. I'll have a movie and fort up soon.

[crazycarlt]

I thought I might use a water system for power, running a constant loop of 'current' under all of the mechanical adders. Whether using a pump-and-plate rotation sensor is optimal or not, I do not know.

Apart from 'dwarfiness,' I surmised that a mechanical system would be faster. After watching your adder work (when not browsing on my blackberry or working, or both) I realized that your pressurized water system is quite fast on its own.

I'm also imagining a 7-seg decimal-to-binary encoder/decoder for more user-friendly number input. 9 switches arranged as a numpad key for 9 drawbridges and 9 floodgates. Possible, I think, but at this stage you're more qualified than I to design such a thing.

I'd love to update you on mechanical dwarfputer experiments, and once I have the time to research and build some I will post my results.

One more question, though: Do you use some special RAWs for 'super workers' that don't need to eat, sleep, or drink and move one tile every frame? (and remove all animals/other races) I imagined that this would be the most efficient way of making megaconstructions or experimenting. My initial forays into complicated castle irrigation were hampered by dwarf moods, desires, and their inexplicable need for food and drink.

So what I really need is a slave force of super dwarf-robots.

P.S. Practical use for a dwarfputer:
Arrange somehow for small waterfalls to be emitted from each adder when its output bit is '1,' build a dwarven counter/divider that fires a huge, high-pressure fountain every time it reaches a prime number, or set up a matrix of spike traps that uses a PRNG (read: cat in a pit) to send ripples and waves flowing back and forth across the killing field. Add donkeys for amusement.

[Kanddak]

Apart from 'dwarfiness,' I surmised that a mechanical system would be faster. After watching your adder work (when not browsing on my blackberry or working, or both) I realized that your pressurized water system is quite fast on its own.

There are definitely delays, especially in propagating carries. If you avoided the rotation sensor and went for the unbelievably impractical fractal design, it would be instant.

I'm also imagining a 7-seg decimal-to-binary encoder/decoder for more user-friendly number input. 9 switches arranged as a numpad key for 9 drawbridges and 9 floodgates. Possible, I think, but at this stage you're more qualified than I to design such a thing.

Yeah, I was playing with some keypad ideas in my head with the thought of eventually building a calculator. I was seriously planning to use pressure plates in a dog pit as the buttons, so that doing calculations consumes goblins.

One more question, though: Do you use some special RAWs for 'super workers' that don't need to eat, sleep, or drink and move one tile every frame? (and remove all animals/other races) I imagined that this would be the most efficient way of making megaconstructions or experimenting. My initial forays into complicated castle irrigation were hampered by dwarf moods, desires, and their inexplicable need for food and drink.

Nope, I play vanilla DF. I have a pretty standard routine for how I begin to establish a fort, and I turn most migrants into masons/mechanics/architects (while not allowing them to use the workshops). That includes putting a 5x5 plot of plump helmets in the soil layer and never having to worry about food again, and trading for a couple pieces of giant cave spider silk cloth and some turtles or cave lobsters. I've only ever lost one mood since my first fort and that was a glassmaker on a sandless map.
Granted, for these kinds of forts I tend to just dig rooms as I need them without any coherent plan, so that they don't really work all too well as long-term forts, but they're good enough for the first few years.

[Random832]

That would be slow.  And Obsidian is not magma proof.

Hatch covers open/close instantaneously, and vanish when open - unlike drawbridges. Also, it doesn't have to be magma-proof to be _over_ magma, this isn't 2D.

[NTheGreat]

Amazing. I've been considering a few things using a combination of water to perform the logic and axles to act as 'wires' between them, but that's still at the paper stage.

It's nice to see that a working adder has finally been created. Now all we need are memory banks, arithmetic units and all the other little odds and ends you find in computers.