Somewhere in a parallel universe...
***
Computer: HA. HA. HA. DIE. INSECTS.
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
Technogibberish
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.
I loaded the following into the memory
data cells
32-00001001
31-10100001
30-00001101
29-00000011
Program cells
1-10111111-binary shift left cell 32 (00010010)
2-11011110-binary shift right cell 31 (11010000)
3-00011101-load cell 30 (00001101)
4-01011111-add 1101 and 1001 (00010110)
5-01111100-subtract 11 from 10110 (00010011)
6-00111011-store 10011 in cell 28
7-10000000-PC to 00000
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.
Memory banks before the test
A dwarf demonstrating the operation of the clock.
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.
Phase 1-1
Transfer accumulator to AR1.
Since the accumulator is empty, nothing happens!
Phase 1-2
Transfer PC to MAR, increment PC+1
PC is empty, so MAR is also empty. Notice the PC+1 now has a 1 in it!
Phase 1-3
Load Instruction register from memory, transfer PC+1 to PC.
Load whatever is in address 00000000. Which is 10111111. Great!
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.
Phase 1-4
Transfer PC+1 to PC
Ok, now PC has been incremented.
Phase 1-5
Write MAR from IR
Ok the instruction says the data is at cell 32 (or 31) so 11111!
Phase 1-6
Execute Bitshift left on memory cell 11111(00001001)
Huzzah! 00010010! Totally expected result!
Ok. Now I will show you the results from the remaining executions:
Phase 2
Execute Bitshift Right on memory cell 11110(10100001)
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.
Phase 3
Execute load cell 30 (00001101)
Hurrah! The accumulator has been loaded from memory!
Phase 4
Execute Add 1101(accumulator) and 1001(contents of cell 11111)
Yay! The adder still works even after I messed with it!
Phase 5
Execute Subtract 11(contents of cell 11100) from 10110 (accumulator)
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.
Phase 6
Execute Store 10011 into cell 28(or 27)
Hoorah! The memory write mechanism works! It was a massive grindfest. The WHOLE BLEEDING EXERCISE was a massive grindfest!
Phase 7
Execute Jump to 00000 if accumulator is not negative.
The program counter is cleared and program will start looping if it were allowed to continue.
Final AnalysisComputer 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.
Author
Topic: Dwarven Computer (Read 175049 times)