Ustuth: Damn the doors are locked. Quick Zon! Pry open the doors with your fingernails!

Zon: It's no good! I just clipped them yesterday!

Ustuth: But the new version isn't out yet!

***

Okay, so I tried to murder all my dwarves. Nobody's perfect Funny way to celebrate the completion of my computer though...

Jong enjoyed toppling something over recently.

This was the first time I deliberately attempted to harm my dwarves, so it didn't turn out so well. Turns out that the computer is too big to flood quickly It was starting to look like the dwarves would starve before they drowned. Then I told them to hide out in the cistern because it would be "safer". I locked the doors and opened the other door.

Well, it turned out pretty safe after all. They all fell into the pit used by the pump, but the pump was still active! It left this little dry spot under the pump

After that I gave up on killing my dwarves and returned to my original universe

I only managed to kill 9 dwarves. Only the marksdwarf drowned, when he got sucked into an output buffer. 1 child fell down the cave river pit and landed in the power plant. The rest fell down the service stairs as I was moving them into the the cistern.

I was really disappointed when the dwarves reacted rather nonchalantly to their imminent demise. They all just continued gathering around the breach. I was hoping they would run around screaming, but I guess I need a lot more water for that.

Or magma.

I had noticed that the last carry bit wasn't being used in the adder. It was sort of an overflow bit. I thought I could rig up a single use pressure plate to it to punish anyone who tried to overflow the computer. hehe

Of course, using a twos complement notation, an overflow would simply mean that the negative has become positive, like -1(11111111)+1=00000000

Ok back on topic! As I said earlier, I have completed my computer and it was a

[size=8]COMPLETE SUCCESS!!![/size][/color]

....

Ok you might want to first take a leisurely look at the completed completed computer here.

For my testing run, I prepared a simple program that would test all all the various functions of the computer. These are load from and store to memory, add, subtract, bitshifting left and right, a conditional jump when the accumulator is not negative, and halt. I couldn't test the halting function as the clock was manually operated.

Well actually the cell numbers start from 0 and end at 31, but that would just confuse everyone. The number in the bracket is what you would expect to see in the accumulator at the execute phase of the fetch cycle.

Ok... I'll be posting up screenshots of all the phases of the first fetch cycle, and then only the results for the remaining executions.

I was testing the clock when I discovered that pumps don't immediately switch off when the power is cut. The first time I tried it, the water cell jumped 6 pumps. After that, the clock was manually operated. I also realized that I needed to connect the decoders to the memory storage cells instead of their output cells, because a 0 to a decoder is also an operation, so it needed to be kept primed.

Not so great. The first time I did this, I discovered a horrible backward power flow problem in the multiplexer. It caused all the bytes in the memory that shared a bit with the currently selected byte to become active as well, leading to disaster. Fixing it took over 1000 mechanisms.

Result? 11010000! The leftmost 1 was retained and the rightmost 1 was dumped!

The first time I did this, I experience the same horrid backward power flow enabling the bitshift left circuit and half of the adder! I had to install triggered gears along the power supply rows in order to break the power transmission.

This one was interesting. I noted that the accumulator was filled completely, then settled into the correct answer. This was because the inputs were inverted before the signals from the memory output multiplexer came in. This is evidence that pumps do not operate instantly.

The program counter is cleared and program will start looping if it were allowed to continue.

Final Analysis

Computer Performance: The computer was incredibly slow. Part of it had to do with the manual operation of the pumps, which needs to be ordered while paused. Still, the testing run took the better part of a in-game month to complete, that is, after the gremlins were ironed out. The biggest source of operational lag is mist generated by falling water. Of course, the gigantic contraption itself generates tons of lag.

Reliability: The computer was fairly reliable, producing the correct results given enough time. However there is a problem with the free draining output buffers. They appear to consume unusually large quantities of water which simply vanish. The losses are much bigger than anticipated evaporation losses. Its possible that the evacuated area under the operation pumps creates a larger pan for the water to evaporate. The water losses tend to cause some glitches, especially for the units at the edge of the shared pool, if allowed to run for too long.

Practicality: Monstrous. Monstrously impractical. The final parts count topped 8500 mechanisms, (excluding those in my other contraptions), 2000 logs (including power supply), 672 pumps, and 1000s of other bits like doors and blocks for the floor of the channels. That's just the materials. I don't think I can adequately describe how grinding linking the 1000s of gears was. I think I'm starting to count in powers of 2. Its absolute insanity. You should be glad the computer doesn't spikes of human bone, or has an image of 0s and 1s in human leather on it.

Conclusion: You can build a programmable digital computer in Dwarf Fortress. Its possible, it can be done. People have done things in Dwarf Fortress for less reason. I really wouldn't recommend it though, unless you happen to be suffering from the same kind of mental illness as me. If you just want to play with dwarven computing, I offer up my save file to the public. Feel free to try out any sort of program you like. I made sure to write enable all the memory cells, even though I didn't have to.

P.S. Also feel free to take advantage of the tower I built. I haven't tried dropping a goblin 140 z-levels yet.

Can we get some "logical blueprints" for some of the trickier bits (like how many buffer registers you needed, and how they're hooked up together)? I want to try my hand at this.

I'm not sure exactly what you need but does this help?

This diagram (which is in the first post) illustrates how the various registers are hooked together. The pressure plates of the output buffer of the register at the base of the arrow is linked to the input gears of the memory cells of the register at the point of the arrow. (I hope this sentence doesn't cause even more confusion)

The internal structure of each register, represented as boxes in the diagram, is mostly the same. The pressure plates of the memory cells are linked to the input gears of the output buffers, except in the case where the register is supposed to activate a decoder, where those same plates are directly linked to the gears of the decoder.

This diagram is only supposed to illustrate the data flows in the computer. I should clarify that the arrow between the memory address register (MAR) and the memory shouldn't really be there, since the MAR only sends the data to the 5-32 decoder. You should also be aware that the MAR, PC and PC+1 are only 5 bits long, so they only need to be hooked to the appropriate 5 bits in an 8 bit register.

The other bit of info you need for a full set of "logical blueprints" are the link tables of the clock and the control unit. These are slightly updated versions of the ones in the first post that I copied from my design manuscript on google docs.

Well its also slightly out of date after modifications I made during testing. Its not necessary to read the memory to use the decoders they are linked to, since the decoders are linked directly to the memory cells of their registers. You could probably dispense with the output buffer of the MAR and the first (or last, depending on how you look at it) 3 digits of the the IR, which operates the control unit decoder.

Of course, if your computer is different, then you should draw up your own link tables and data transfer diagrams. It should be sufficient to guide you when you are doing the linking phase of construction.

I recommend looking at a few sites if you're interested to learn more about designing your own computer.

This one belongs to some guy who apparently built a computer out of various prefabricated integrated circuits. While the details of electronic circuitry are somewhat irrelevant to dwarven computer construction, I thought his design considerations and description on how his computer was supposed to work was really useful when I was researching this project.http://cpuville.com/