Post by: Jong on February 16, 2010, 01:12:20 pm
Updated:19/03/10
EDIT:
BWAHAHAHAHA!!!
I FINALLY SUCCEEDED!!!
Click Here to see my testing results
http://www.bay12games.com/forum/index.php?topic=49641.msg1094222#msg1094222 (http://www.bay12games.com/forum/index.php?topic=49641.msg1094222#msg1094222)
Introduction
One day, I commented to my friend that my fortress power plant was far too large. He suggested I build a dwarf computer to soak up some of that excess power. I decided to take him up on that challenge, so currently I am drawing up plans for a dwarven computer and I have serious intent to actually construct it.
I have never studied computer science and prior to this project, had no clue how computers actually functioned. Based on what I know now building a dwarven computer is starting to look like it requires even more power generation!
A slight digression into the precedents of dwarven computing. The wiki covers in detail a number of simple logic mechanisms. The page on computing also contains a few links to mechanical marvels such as automatic magma traps, seven segment displays, adders of various sizes and even an attempt to construct a dwarven calculator. What I am attempting is essentially a fully automated calculator. This is the true nature of a computer.
Contents
- To do list
- Testing Schedule
- Design notes
- Power sensor
- Memory Cell
- Registers
- Memory Unit
- Decoder
- Memory unit Registers
- Memory unit architecture
- Designing the machine language
- Design for the Arithmetic Logic Unit(ALU)
- Design for a half adder
- Design for a full adder
- Design for an 8-bit ripple carry adder-subtracter
- Design for a carry-look-ahead adder
- Design for ALU architecture
- Under construction
Things to do:
Design memory cells
Design registers
Design memory unit
Design clock
Design bus
Assemble designs
Draw up blueprints
Construct computer
...
Profit!
Warning! Giant Wall of Text!
Spoiler (click to show/hide)
Post by: Steveninn on February 16, 2010, 01:26:10 pm
Post by: Shrike on February 16, 2010, 01:38:17 pm
Can it play DF?
I'm sure there have been a number of brainy dwarves who have attempted this, but I'm very interested in seeing a successfully completed version.
Are you planning to do I/O in dec or bin? Binary would be easier to implement, but if you wanted to do decimal, you could lay out some levers in a keypad formation.
Don't forget to put in a clear function lever to reset to the start state, in case some smartypants tries to throw in a divide by zero.
Post by: Jyppa on February 16, 2010, 01:43:37 pm
As for "fast on and off", the optimal design for speed might be to stack another pump on top of the first, and have it turn off whenever the other one turns on. It would pump the water to the tile right above the original source tile where it would drop down to reset the system perfectly, which preserves water and reduces the reset time to exactly 100 steps, reliably. You only need to pond fill the one tile once for each sensor, as well, which might be more convenient than an extensive water dispensal system.
Post by: Shinziril on February 16, 2010, 02:38:38 pm
Also, another easy way to remember the formula for a decoder is that each unique combination of n inputs is the binary representation of the numerical designation of the output (so for n = 2; 00 = 0, 01 = 1, 10 = 2, 11 = 3) and so on. Then you set up the combination of normal and inverted gates such that the specific output is TRUE for its numerical designation (I.E., output 0's logic is (NOT1)&(NOT2), output 2's logic is (NOT1)&(2), etc).
Post by: Jyppa on February 16, 2010, 02:46:59 pm
Post by: Shinziril on February 16, 2010, 03:19:31 pm
Side view:
Code: [Select]
*
#_<%_#
#_%>^#
#_#*##
######
Top view
Code: [Select]
Bottom Pump Top Pump
### ###
#^# #.#
#%# #%#
#%# #%#
#.# #.#
### ###
The gear inputs come in from the top and bottom, as you can see in the side view. You fill the level up to 7/7 on the level of the walkable tile of the bottom pump, so removing one tile for the pressure plate simply creates a sloshing 3/7 and 4/7 tile pair (which will not evaporate). The top pump drops the tile back to the beginning. Put two of these side-by-side (one for write, one for read) and you have a memory cell. You can dig out a little more by the bottom input gear for more space if you need it.
This removes the need for a complicated water supply system for all 32 registers, which is quite nice (although it is going to use a lot of mechanisms and power). Also, the read/write gears are no longer on the same z-level as the actual pumps they are powering, which makes it a little less intuitive to build, but I think it'll be worth it.
I love it when an idea comes together.
EDIT: Did some prototyping, here's a full diagram of an 8-bit register using this model:
Level 0:
Code: [Select]
*=*===*=*===*=*===*=*===*=*===*=*===*=*===*=*=C
#W#R# #W#R# #W#R# #W#R# #W#R# #W#R# #W#R# #W#R#|
#I#o# #I#o# #I#o# #I#o# #I#o# #I#o# #I#o# #I#o#*
##### ##### ##### ##### ##### ##### ##### #####
#+#+# #+#+# #+#+# #+#+# #+#+# #+#+# #+#+# #+#+#
##### ##### ##### ##### ##### ##### ##### #####
Level 1:
Code: [Select]
#D#D# #D#D# #D#D# #D#D# #D#D# #D#D# #D#D# #D#D#
#^#^# #^#^# #^#^# #^#^# #^#^# #^#^# #^#^# #^#^#
#%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%#*
#%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%#
#.#.# #.#.# #.#.# #.#.# #.#.# #.#.# #.#.# #.#.#
##### ##### ##### ##### ##### ##### ##### #####
Level 2:
Code: [Select]
##### ##### ##### ##### ##### ##### ##### #####
#.#.# #.#.# #.#.# #.#.# #.#.# #.#.# #.#.# #.#.#
#%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%#*
#%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%# #%#%#
#.#.# #.#.# #.#.# #.#.# #.#.# #.#.# #.#.# #.#.#
##### ##### ##### ##### ##### ##### ##### #####
Level 3:
Code: [Select]
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
+.+.+ +.+.+ +.+.+ +.+.+ +.+.+ +.+.+ +.+.+ +.+.+
+*=*===*=*===*=*===*=*===*=*===*=*===*=*===*=*=*
+N+N+ +N+N+ +N+N+ +N+N+ +N+N+ +N+N+ +N+N+ +N+N+
+.+.+ +.+.+ +.+.+ +.+.+ +.+.+ +.+.+ +.+.+ +.+.+
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
Key:
# = Wall, + = Floor, . = Open Space, * = Gear, %% = Pump, ^ = Pressure Plate, = or | = Horizontal Axle, W = Write, R = Read, I = Input, o = Output (linked to the appropriate ^), N = NOT-Input, C = Circuit Select, D = Door
Notes:
Need floor between individual memory bits on level 3 (to support horizontal axle), floor under D and ^ on level 1, floor under the pumps on level 2 (both tiles, to prevent power transfer between level 1 and level 2), and floor under the upper power gears on level 3 (to prevent bypassing the NOT-input gears).
This is probably easier constructed than dug out. You'll probably want "scaffolding" stairs around each memory bit (the space left between the bits makes this easy).
When constructing pumps, leave the wall orthagonally next to the unwalkable tile of the pump undone, so that the workers can get in diagonally to work on the pump but won't be able to trap themselves in when you finish the wall.
This memory register should use about . . . 500-odd power? Definitely less than 600, but more than 500.
Post by: Jong on February 16, 2010, 09:23:13 pm
One question though: Can gears be built on open space? If so, what happens when they are toggled?
Yes but is it turing complete?
Can it play DF?
Well its turing completeness would depend on the instruction set the computer can execute, which will be unveiled soon. According to the document I am reading, it is complete, which means that any function can be written as a combination of the instructions, given enough memory, and time!
Unfortunately since the prototype will only have a 5-bit address space, it is highly unlikely that you can play DF on it!
Post by: Shinziril on February 16, 2010, 10:10:26 pm
Post by: Jong on February 17, 2010, 08:06:43 am
A gear assembly can be built so that it is unsupported by solid floor and designated as "hanging" in the Query menu. If you toggle it, it will still be supported by other machinery, but (and this is an important "but") it will cease supporting other machinery. So building a toggleable gear assembly on top of another gear assembly, connected to a gear assembly on solid ground, is perfectly fine. But putting a windmill (or another gear assembly) on top of or beside that toggleable gear assembly, unsupported by floor, is not fine.
I see. I suppose the hanging gear assembly must be supported by other machinery in any case. What I had in mind was something like this:
Code: [Select]
TP
# %% #
# ####
######where T is the toggled gear and P is a supported powered gear, rather than
Code: [Select]
**TP
# %% #
# ####
######I suppose I would have to build an additional support gear next to T if the logic chain is longer than 1. Can a lone axle attached to nothing else provide support?
I have updated my design and it now includes details of the machine instruction set and designs for a full 8-bit ripple carry adder-subtractor. Still a long way to go to a full computer!
Post by: starburst98 on February 17, 2010, 11:16:52 am
Post by: Kanddak on February 17, 2010, 01:47:37 pm
I always build a huge elevated tank of water to feed all my logic systems, and control its flow with floodgates and 1x1 drawbridges. A single stack of pumps runs the whole thing.
Post by: shadow_slicer on February 17, 2010, 01:55:54 pm
You should only need one cell to hold the water representing the bit with a pressure plate for reading. Then you can have that pressure plate toggle a gear assembly linked to the memory output.
So for a single bit where the pressure plate in each of four memory cells is connected to gears i o p q with corresponding read lines (from decoder) connected to gears r s t u, the combiner at the end is:
Code: [Select]
*=*=*=*=Power
i o p q
r s t u
*=*=*=*=Output
If you need the output to be triggered by a pressure plate, you could even share a single "output buffer" among all of the memory cells. This buffer would basically be another memory cell, only it would used the output from the combiner as its input. This should save a significant amount of space and power.
Post by: Stas on February 17, 2010, 04:54:13 pm
You should make it so, when a /b/tard tries to Divide by Zero, the computer destroys itself.
Post by: Keldor on February 17, 2010, 05:21:54 pm
Epic.
You should make it so, when a /b/tard tries to Divide by Zero, the computer floods the fort. With magma.
Fixed.
Post by: Earth Striker Lurin on February 17, 2010, 07:19:54 pm
period.
Post by: Innominate on February 17, 2010, 08:02:04 pm
Post by: Jong on February 18, 2010, 02:59:14 am
About the memory cells, I don't see why you need a separate cell for reading and writing.
You should only need one cell to hold the water representing the bit with a pressure plate for reading. Then you can have that pressure plate toggle a gear assembly linked to the memory output.
So for a single bit where the pressure plate in each of four memory cells is connected to gears i o p q with corresponding read lines (from decoder) connected to gears r s t u, the combiner at the end is:Code: [Select]*=*=*=*=Power
i o p q
r s t u
*=*=*=*=Output
If you need the output to be triggered by a pressure plate, you could even share a single "output buffer" among all of the memory cells. This buffer would basically be another memory cell, only it would used the output from the combiner as its input. This should save a significant amount of space and power.
An excellent optimization. I must have missed it because I was designing everything modularly. I was thinking that it was a bit wasteful for each register to have its own output buffer. You forgot the Read-out signal though. Thats an additional gear.
I was thinking of wiring the decoder directly into the memory banks to save an output step. If I applied this method, it could plausibly still be done but the complexity is daunting, as the each 32 outputs of the decoder need to split into 8 for each bit and routed to the appropriate output buffer bit. That's 256 power lines and they can't be crossed :( I would then still need to route the decoder signal to the memory cells. So its a trade off. 1. I can skip an output step, save 32 output buffers from the decoder but build 256 output buffers for the memory bank. 2. Keep the decoder output buffers but avoid build 256 others. 3. Go for mind numbing multi z-level power routing.
Well its a good point to keep in mind when doing optimization for the final blueprints.
My experience with logic has been that toggling a bunch of pumps mechanically is a huge hassle and not the way to do things.
I always build a huge elevated tank of water to feed all my logic systems, and control its flow with floodgates and 1x1 drawbridges. A single stack of pumps runs the whole thing.
Really? My impression of fluid logic was that it was slower and less reliable. The 100 step delay for bridges and floodgates is a real downer. Plus I didn't want to have to deal with sticky triggers. Perhaps I was mistaken? I haven't really considered it.
I was probably dazzled by the steampunkness of employing a huge number of gears to do calculations.
Post by: Shinziril on February 18, 2010, 11:11:52 am
It is a little slower due to toggling delays, but that may or may not be acceptable to avoid having to route power everywhere. The "reliability" issue is solved using a high-pressure cistern to ensure fast water delivery (and diagonal drains to prevent pressurized outflow). I think I'll work on some alternate fluid-logic designs and post them, but you can use whichever seems easier.
You could even use some sort of hybrid-logic system - some logic operations are just easier in mechanical logic.
Post by: shadow_slicer on February 18, 2010, 03:06:19 pm
I was thinking of wiring the decoder directly into the memory banks to save an output step. If I applied this method, it could plausibly still be done but the complexity is daunting, as the each 32 outputs of the decoder need to split into 8 for each bit and routed to the appropriate output buffer bit. That's 256 power lines and they can't be crossed :( I would then still need to route the decoder signal to the memory cells. So its a trade off. 1. I can skip an output step, save 32 output buffers from the decoder but build 256 output buffers for the memory bank. 2. Keep the decoder output buffers but avoid build 256 others. 3. Go for mind numbing multi z-level power routing.That's probably true, but I don't think the multi-z-level routing would be that bad. If you use the output from the decoder directly, you don't really have to split the decoder signals for each bit. Instead you can have the output from the decoder be the power line for that row of memory (a row consisting of 8 bits). Then you can tap into that "power" line somewhere and extend it so it is about 5 z-levels high. Then link up the final output buffers (2 bits per level, one one each side of the "column"). Although you can't put the output buffers on top of each other or on the same level, you should have plenty of room to stagger them.
Spoiler: A simple example (click to show/hide)
Post by: Jetsquirrel on February 18, 2010, 05:35:14 pm
Computer:*crackling noise* yes?
Dwarf:What is the answer to life?
Computer: Come back in 102 million years
*102 million years later*
Dwarf: Do you know the answer to life now?
Computer: The Answer to life is...
*dwarf gasping*
Computer: 42
Dwarf: FUUUUUUUUUUUUUUUUUUUUUUUU
Post by: zecro on February 18, 2010, 10:42:49 pm
They would call them "gremlins."
Post by: Jong on February 18, 2010, 11:55:15 pm
If dwarves build a computer, they wouldn't call errors bugs.
They would call them "gremlins."
Ahaha! I read about gremlins. Imagine the chaos they would cause as they ran through the computer, especially if I left the levers used to toggle the gears lying around after construction. Thank goodness I plan to build it using the current version. Future computer architects beware! ;D
(they will literally be computer "architects")
Update: I've drafted a design for carry-look-ahead adders and it is vastly superior in all aspects to the ripple carry adder. Fluid logic users might want to take note.
EDIT:I also decided that I ought to hide my giant wall of text with spoiler tags. Perhaps I should have done that from the start.
Post by: immibis on February 19, 2010, 01:36:23 am
This design is bit-addressable so to get more than one bit per address you'd need to have multiple smaller (or not) ones and connect the address inputs. The control logic section on that page might be incorrect, and the design of the memory itself isn't tested yet, though.
Post by: Mechanoid on February 19, 2010, 01:52:00 am
They would call them "gremlins."And de-buggers would be axe dwarves.
Post by: Jong on February 19, 2010, 04:52:09 am
I had an idea for (relatively) small and probably power-efficient, but complicated and slow, memory here: http://df.magmawiki.com/index.php/User:Immibis/RAM/RAM (http://df.magmawiki.com/index.php/User:Immibis/RAM)Broken link (fixed)
This design is bit-addressable so to get more than one bit per address you'd need to have multiple smaller (or not) ones and connect the address inputs. The control logic section on that page might be incorrect, and the design of the memory itself isn't tested yet, though.
Hmm.. While I am intrigued by the possibility of 1 tile bits, I see that your design requires reflooding to read and write from the memory.
My ideal computer should be able to complete the requested operation within 100 steps. The reason for this is that the computer is regulated by a clock, and the minimum cycle time of a automatic dwarven repeater is 100 steps.
Of course, I'm not so optimistic that the computer will be able to perform so quickly so this computer will be manually clocked. I know that the reset time for the pressure plates is 100 steps but I may be able to contrive a clock cycle where the output buffers have time to reset before being used again.
The current plan for the manual clock involves a single lever, so I can test various clock speeds. It is an 8 step clock cycle so even the ideal automatic dwarven computer would only be able to run one instruction every 800 steps.
According to the clock thread, a dwarven day is 1200 steps, so if a dwarven day is the same length as ours, that makes the clock speed of an ideal dwarven computer a zippy 1/7200 Hz.
BTW clock speed is determined by the frequency of the oscillator, not the frequency of execution.
Update: I've completed the draft of the ALU design. Next will be tricky bits like the timing and control circuits.
Post by: Safe-Keeper on February 19, 2010, 04:54:36 am
Quote
You should make it so, when a /b/tard tries to Divide by Zero, the computer floods the fort. With magma.You could make a DF GlaDOS!
"Good neeews..."
Post by: Gazz on February 19, 2010, 03:40:26 pm
Quote from: Jong
(they will literally be computer "architects")I've heard the term Systems Architect before but I didn't quite make that connection...
Post by: Jong on February 24, 2010, 01:49:40 am
I've completed the design of all the components of the computer. All that's left is to build and test it.
Post by: Mechanoid on February 24, 2010, 06:35:12 am
Post by: Evil One on February 24, 2010, 03:00:51 pm
Post by: jryan on February 24, 2010, 06:33:48 pm
Post by: They Got Leader on February 24, 2010, 06:39:03 pm
Post by: Innominate on February 24, 2010, 07:01:17 pm
Now the question to blow your mind: Will it be able to play Dwarf Fortess?!If you had a large enough embark perhaps. The hard part would be that the graphics are basically limited to hatches covering magma, water or nothing in either the open or closed state.
Well no I lie, the hard part would be everything. But apart from that, simplicity itself.
Post by: Jong on February 27, 2010, 05:04:45 am
Construction estimates
Component summary:
Gear assemblies: 2970 (853 disengaged gears, 448 engaged gears, 1669 normal un-triggered gears)
Axle tiles: 1898
Screw pumps: 672
Pressure plates: 365
Doors: 835
Link jobs: 1369++
Paving tiles: 1594
Material summary:
7675 mechanisms
2266 blocks
1000+ logs
835 doors
672 enormous wooden corkscrews and pipe sections
I'm not sure how accurate my construction estimates are, but I'm not going to count any more pixels!
Aside from the totally crazy material counts, the computer is not really that huge. It fills up about half of my 3x3 site and occupies 4 z-levels (The fifth contains just a few components). It is probably feasible to build a similar computer on just about any site with running water and wood. I guess that digging out the space should generate enough stone for the task.
Post by: Itnetlolor on February 27, 2010, 12:46:54 pm
Post by: Pkassad on February 27, 2010, 05:01:24 pm
What are you going to do regarding wood? Edit raws, hack the embark?
Hack the forest down and imports? You could also start with several hundred towercaps...
Post by: The Mad Engineer on February 27, 2010, 05:11:02 pm
Post by: Don Blake on February 27, 2010, 06:44:07 pm
You know I have the greatest enthusiasm for our mission, Urist.
Post by: Shinziril on February 27, 2010, 09:27:09 pm
What are you going to use the computer for?
Mad, you of all people should know the correct answer to that question: absolutely nothing.
Nothing useful, at any rate.
After all, if it actually did something, what would be the point?
Post by: darkrider2 on February 27, 2010, 10:45:38 pm
Quote
After all, if it actually did something, what would be the point?
this has to be SIGGED!
Post by: Innominate on February 28, 2010, 02:37:54 am
No no no, uselessness is not the point of dwarven engineering.What are you going to use the computer for?
Mad, you of all people should know the correct answer to that question: absolutely nothing.
Nothing useful, at any rate.
After all, if it actually did something, what would be the point?
The point of dwarven engineering is overwhelming a tiny problem with
After all, would you rather have a hall filled with weapon traps or one covered in spear traps repeating in an unpredictable pattern, triggered by a forlorn kitten at the bottom of your fortress?
Post by: Mechanoid on February 28, 2010, 04:01:06 am
Quote from: Jong
Material summary:You can easilly modify the products of any currently existing reaction to give you whatever material you want or need:
7675 mechanisms
2266 blocks
1000+ logs
835 doors
672 enormous wooden corkscrews and pipe sections
[PRODUCT:100:10000:TRAPPARTS:NO_SUBTYPE:STONE:GRANITE]
[PRODUCT:100:4000:BLOCKS:NO_SUBTYPE:STONE:GRANITE]
[PRODUCT:100:3000:WOOD:NO_SUBTYPE:WOOD:GIANT_SHROOM]
[PRODUCT:100:2000:DOOR:NO_SUBTYPE:STONE:GRANITE]
[PRODUCT:100:1000:PIPE_SECTION:NO_SUBTYPE:WOOD:GIANT_SHROOM]
[PRODUCT:100:1000:WEAPON:___:WOOD:GIANT_SHROOM]
Where ___ is whatever the giant corkscrew trap part is called. Just copy/paste that entire product list into a existing reaction like the steel reaction, and the next time the reaction is finished all those items will pop out of the smelter. Then you save the game and delete the product list to get your normal steel reaction back to normal.
... Then all you have to do is assemble it. :suicide:
Post by: wagawaga on February 28, 2010, 09:34:07 am
Post by: Scruga on February 28, 2010, 09:50:34 am
Post by: DennyTom on February 28, 2010, 11:03:48 am
See now, the story of the original computer "bug" was a moth in the computer. So does that mean if you find an elf in your dwarf computer, does that make your problem an "elf"?
I completely agree - we must wait for the first prototype. What will cause the first unexpected error, it is!
Post by: Diablous on February 28, 2010, 11:06:14 am
Post by: Safe-Keeper on February 28, 2010, 11:48:19 am
Now the question to blow your mind: Will it be able to play Dwarf Fortess?!This is a ¤computer monitor¤. All craftsdwarfship is of the highest quality. The monitor is displaying an image of a rabbit in pixles. On the head of the rabbit is the image of a pancake. The pancake is screaming.
Post by: wagawaga on February 28, 2010, 12:00:37 pm
Post by: Jong on February 28, 2010, 12:01:06 pm
Well now that I have very detailed blueprints, completion of this project is only a matter of time and fps, which has been down by half since the completion of the main tower.
Post by: wagawaga on February 28, 2010, 01:36:52 pm
Post by: Firehound on February 28, 2010, 01:47:16 pm
Post by: TheDancinZerg on March 01, 2010, 03:44:10 am
Post by: lastofthelight on March 01, 2010, 04:19:48 am
Post by: Gazz on March 02, 2010, 03:55:00 pm
Will you call the fortress Shodan? =)
That would one-up all doomsday devices. Everlasting, uncaring doom. Fascinating! =)
Post by: Jong on March 02, 2010, 11:39:46 pm
I'm going to try to minimize the amount of stone produced so I'll be using access tunnels rather than just clearing out the entire space.
EDIT: I just discovered that my liaisons are dead. I'm not exactly sure how it happened but I turned off invaders. It's possible they died of old age. Anyone know how I can revive them?
Post by: neek on March 04, 2010, 09:15:51 pm
Post by: kg333 on March 05, 2010, 12:04:44 am
This is some hardcore computer engineering...you might want to seriously look at going into the field if you like doing this for fun.
KG
Post by: Flaede on March 05, 2010, 12:12:30 am
Post by: SethCreiyd on March 05, 2010, 12:33:45 am
Post by: Jong on March 06, 2010, 04:12:30 am
Progress is slow in dwarf time, as I have only 22 adult dwarves. At least FPS is maintained in the 60-80 range, so real life speed is moderate. Constructing screw pumps is much slower than I am used to because it is a 3 component building. Its nearly as annoying as building water wheels (water wheels have a tendency to collapse suddenly when you are building lots of them).
My strategy to minimize the pain of the linking phase of construction is to build all inactive components first, such as screw pumps, pressure plates, axles and unlinked gears. I will then build and link the active gears one set at a time. This should ensure that the gears I want to link will be at the end of the building list. I also plan to build all the active gears out of orthoclase so I can easily see which gear is being linked. I have a small stock pile of cobaltite mechanisms for use in the adder as it is the most complex gear assembly.
Was it necessary to build a scale Space Needle fort this project? ;)
It was already there!
Post by: Wh1tefang12 on March 06, 2010, 09:04:25 am
Post by: archivis on March 06, 2010, 12:56:55 pm
But very spiffy stuff, I hope you manage to get it completed! Good luck!
Post by: neek on March 09, 2010, 11:09:12 pm
Was it necessary to build a scale Space Needle fort this project? ;)
It was already there!
I'm actually quite impressed with the fort design thus far. It's... magnificent. The sprinkler design for the tower cap farm is also ingenious. This computer will also be awesome. I'm curious, because I didn't read it (or missed it), but how do you intend on handling output of processes?
Post by: Scruga on March 10, 2010, 03:57:15 am
Post by: seanose on March 10, 2010, 11:49:39 am
Would it be possible for the dwarf computer to, say, *unpause* another dwarf fortress? Or to assign tasks via the manager? Or some other simple interface, where input is passed from the internal-nested-DF-game to the dorfputer, stored in memory, some logic test or somesuch is passed, and the dorfputer sends a simple signal back to the internal-nested-DF-game?
Maybe using whatever magical interface that Dwarf Therapist et al use.
One could probably (if it would ever work at all) get such a metaputer playing without having a such a "real" computer like this playing the outer role--just a typical logical gate or something. But with this level of real computer in the outer role, and with good input-output interaction to the inner fortress, I think it might be surprising how much of DF it could play...
Post by: Schilcote on March 10, 2010, 02:19:02 pm
What I would like to have would be a fully automatic management system, switching pumps on and off, enabling and disabling access to brewries and food stockpiles, and coordinating some form of fortress defense against invaders and flooding.
Post by: Shinziril on March 10, 2010, 02:53:30 pm
Of course, such a clock system would have its own problems (like the access doors to the stockpile closing before all the dwarves have left, trapping them in there until they die). It's your call as to whether you want to figure out a way to prevent this, or deliberately leave it in to mess with your dwarves. (I'm sorry,
Post by: seanose on March 10, 2010, 05:44:07 pm
This is really incredibly clunky and complicated, of course. (Yay!) There's different levels of clunkiness: (i) you manually do all this inside a single fortress just by spotting that it's time to cut again (very easy and natural); (ii) you set up a clock etc. inside a single fortress timed to open a floodgate or somesuch; (iii) you run this process through an external dorfputer fortress, which is passed signals from the inner fortress, and basically behaves more like the first option, (i) above, such that the external fortress "recognizes" when it's time to do things, and, say designates an area for cutting.
The difference is that, in some meager sense, option (iii) is like artificial intelligence, trying to figure out how to run a game (a game which is separate from itself), whereas (ii) is "just" a game, where you stay in context, and imagine dwarves making machines to do things for them. In option (ii), the dwarves build a computer they use themselves; in option (iii), the dwarves build a computer which controls a game that you can imagine them looking at and laughing from outside. ("Mini-dwarves!")
I find this pretty interesting!
Post by: Sysice on March 10, 2010, 09:22:00 pm
There are no words.
Except that you win dwarf fortress if you build this. Yes.
Post by: NRN_R_Sumo1 on March 10, 2010, 09:52:47 pm
"This is a sand castle"
"This is a sand computer"
Damn kids.. and their.. smart.. thinking stuff..
Post by: Naresomez on March 10, 2010, 11:48:34 pm
It... how... I... but... what...
There are no words.
Except that you win dwarf fortress if you build this. Yes.
This project will only lead to sadness...
I believe he will end up tantruming, sending his family into a tantrum spiral, effecting his nieghborhood, then community, then state/province, then his country, then the world.
Post by: TheDancinZerg on March 11, 2010, 07:40:56 am
Post by: Schilcote on March 11, 2010, 08:07:07 pm
Schilcote,
(BLABLALBALABLBALABL)
I find this pretty interesting!
The only thing we can't (theoretically) do yet with dwarven computer systems is make dwarves do things (and even that's can be done, but only on a level of allowing/disallowing access to a workshop that has tasks queued up on repeat). What I think we should have are "Dwarven PA systems", or very large bells. We'd be able to link the bell up to a macro of sorts, I.E. when Schist bell rings, your tower-cap farm is designated for chopping, when Olivine bell rings, your wrestling squads go on duty and guard the entrances, when Obsidian bell rings, your automatic obsidian farm is designated for mining, and when Microcline bell rings, the magma pipe is designated for mining and the doors to the food and booze stockpiles slam shut. You'd ring the bell the same way as any other mechanical device (with a mechanical trigger).
Also, we should probably have the option to link gear assemblies (or something like them) to mechanical devices, so we don't have to open a floodgate to let water run over a pressure plate, then close that floodgate and then open another one to let the water out, then close that floodgate and wait for whatever your machine wants done to finish, then repeat the process. It'd be simpler to design.
Post by: Jong on March 13, 2010, 11:52:39 am
I'm actually quite impressed with the fort design thus far. It's... magnificent. The sprinkler design for the tower cap farm is also ingenious. This computer will also be awesome. I'm curious, because I didn't read it (or missed it), but how do you intend on handling output of processes?
Well theoretically I could hook up the output of say, the accumulator, and link it to a row of powered gears and you could see the output there. But I decided not to bother with that at this point and troubleshoot the computer by staring at spinning pumps ;D
If I was really ambitious I could install a 7 segment display (http://mkv25.net/dfma/movie-1745-dwarfputerv01), but one megaproject at a time!
On the subject of using DF to play DF, I think that while it may be possible, you can save yourself a lot of pain and lag by just getting the external program to do it directly.
I doubt that a dwarven computer could perform complex tasks as some of you are envisioning. We are all probably too accustomed to our magic black boxes that a capable of such a wide array of things. The sad truth is that a modern computer is simply an automatic calculator of stunning speed and power. A dwarven computer is not fast, and trying to make it more powerful will simply make it even more laggy. I agree with Shinziril that building a dedicated system is better for doing something actually useful. I believe early computers took a similar approach..
Update: (http://mkv25.net/dfma/map-8238-razorlength) I have completed the first stage of construction. All non-linked components are in place. That was the easy part :D
Now I need to put in the linked gears. Its going to be a long hard slog, step by step, testing all the way, and backing up in case something goes horribly wrong ;D
I have also tested my adder (http://mkv25.net/dfma/movie-2018-8-bitmechanicaladder) and it appears to be fully functional.
The Memory Banks
(http://img28.imageshack.us/img28/6387/memorybanks.jpg)
Post by: NRN_R_Sumo1 on March 13, 2010, 02:29:27 pm
Post by: Innominate on March 13, 2010, 11:13:44 pm
Took me a minute to realize those were pumps, totally thought those were cows.I had the same thought. You could probably figure out some system to use creature logic instead of fluid logic, but it would almost certainly be less compact.
Then again, a cowputer is almost worth it.
Post by: Jong on March 18, 2010, 11:36:25 am
***
Spoiler (click to show/hide)
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 :P 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 ;D
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
Spoiler (click to show/hide)
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 (http://mkv25.net/dfma/map-8269).
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
Spoiler (click to show/hide)
A dwarf demonstrating the operation of the clock.
Spoiler (click to show/hide)
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.
Spoiler (click to show/hide)
Since the accumulator is empty, nothing happens!
Phase 1-2
Transfer PC to MAR, increment PC+1
Spoiler (click to show/hide)
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.
Spoiler (click to show/hide)
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
Spoiler (click to show/hide)
Ok, now PC has been incremented.
Phase 1-5
Write MAR from IR
Spoiler (click to show/hide)
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)
Spoiler (click to show/hide)
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)
Spoiler (click to show/hide)
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)
Spoiler (click to show/hide)
Hurrah! The accumulator has been loaded from memory!
Phase 4
Execute Add 1101(accumulator) and 1001(contents of cell 11111)
Spoiler (click to show/hide)
Yay! The adder still works even after I messed with it!
Phase 5
Execute Subtract 11(contents of cell 11100) from 10110 (accumulator)
Spoiler (click to show/hide)
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)
Spoiler (click to show/hide)
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.
Spoiler (click to show/hide)
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 (http://dffd.wimbli.com/file.php?id=1929) 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. :P
Post by: JimiD on March 18, 2010, 11:59:01 am
I was hoping you would deliver on this, and you have, in spades.
I suspect you have to programme silicon computers to appreciate this properly, which I dont, but even so. Greatly impressed.
This will go down in legend.
Post by: Scruga on March 18, 2010, 12:09:02 pm
Post by: Sphalerite on March 18, 2010, 12:58:01 pm
Now I feel compelled to make one.
Post by: kg333 on March 18, 2010, 06:29:25 pm
KG
Post by: darkrider2 on March 18, 2010, 07:47:23 pm
Post by: Jong on March 18, 2010, 09:28:38 pm
Post by: Naresomez on March 19, 2010, 12:00:06 am
Hmm is that even possible? I've only seen "Bay Watcher" and "Escaped Lunatic".
If the mods wish it, so it shall be.
Post by: Leotto on March 19, 2010, 01:14:20 am
See now, the story of the original computer "bug" was a moth in the computer. So does that mean if you find an elf in your dwarf computer, does that make your problem an "elf"?
Apparently it's "evaporation".
Post by: Jong on March 19, 2010, 06:28:09 am
I think I shall erect a monument somewhere in my fort.
EDIT: I'm thinking something along the lines of a gear assembly in a circle. Kind of like the symbol of the Galactic Empire...
Post by: Shinziril on March 21, 2010, 12:32:42 pm
Post by: Jong on March 22, 2010, 08:32:30 am
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?
(http://img202.imageshack.us/img202/4668/datatransfers.png)
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 (http://docs.google.com/Doc?docid=0AdISzBuNg6ZWZGd0d2t4YjlfMjJ0ejlzc2dnaA&hl=en) on google docs.
Oscillator Link table
O1 Read accumulator, write AR2, write IR, write MAR
O2 Read PC, write MAR, activate ALU (adder select, C0=1), write PC+1
O3 Read MEM, read MAR. activate decoder, write IR
O4 Read PC+1, write PC, write MAR
O5 Read IR, write MAR, write PC+1
O6 Execution (read IR, turn on control unit)
Control unit link table
O0. Read memory, read MAR, activate decoder, write accumulator, select transfer
O1. Read accumulator, write memory, read MAR, activate decoder
O2. Read memory, read MAR, activate decoder, read AR2, Send Add signal to ALU (adder select), write accumulator
O3. Read memory, read MAR, activate decoder, read AR2, Send Subtract signal to ALU (adder select, C0=1, invert input A), write accumulator
O4. Read IR, write PC if ACC7=0
O5. Read memory, read MAR, activate decoder, Send Shift left signal to ALU (SHL select), write accumulator
O6. Read memory, read MAR, activate decoder, Send Shift right signal to ALU (SHR select), write accumulator
O7. Cut power to oscillator.
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/ (http://cpuville.com/)
This other document I found was incredibly useful and I really based a lot of my computer on it. It states really concisely exactly what I need to build a minimal computer, what components are necessary and how to organize them, what functions I needed, how a fetch-execute cycle looks like.
http://csclab.murraystate.edu/bob.pilgrim/405/DigLogic_Apx_A_The_Very_Simple_Computer.pdf (http://csclab.murraystate.edu/bob.pilgrim/405/DigLogic_Apx_A_The_Very_Simple_Computer.pdf)
Well I hope that helps you out. Unless you meant something else?
Post by: Shinziril on March 22, 2010, 09:49:44 am
Shinziril withdraws from society . . .
Post by: HastyLumbago on April 09, 2010, 04:15:37 pm
I mean, don't get me wrong. I suck at magma. It doesn't really ever do anything for me but cause Fun, but is my misunderstanding so complete?
Post by: Diablous on April 09, 2010, 04:16:07 pm
OK, so water evaporates, right? And magma doesn't? Also, IIRC, magma doesn't mist up, right? So doesn't that make magma a better choice for computing?1/7 magma evaporates, I think.
I mean, don't get me wrong. I suck at magma. It doesn't really ever do anything for me but cause Fun, but is my misunderstanding so complete?
Post by: Sphalerite on April 09, 2010, 05:16:30 pm
Post by: Urist Imiknorris on April 09, 2010, 06:28:31 pm
I need to do something with this.
Using magma.
Post by: Z1000000m on April 09, 2010, 06:51:26 pm
1/7 magma and water both evaporate, although I think magma is much slower. Both water and magma should make mist when they fall, although that shouldn't really matter for making a computer. And magma flows much, much more slowly when not pumped, and doesn't pressurize from gravity alone.
magma mist only appears after a cave in afaik
Post by: TheDancinZerg on April 09, 2010, 07:38:46 pm
Post by: Jyppa on April 09, 2010, 07:58:38 pm
Post by: DrJonez on April 10, 2010, 12:24:29 am
Makes me want to look into doing one of these myself.
How long do you think it took you to do this, including design/reading/constructing it in DF/etc?
Post by: Gabeux on April 12, 2010, 03:47:04 pm
"Someone actually won DF!"
Awesome!
Post by: gamerman on April 12, 2010, 04:28:08 pm
Post by: TheMirth on April 12, 2010, 04:56:45 pm
Quote
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.Instead of cutting power, why not cut access to water for the pumps with hatches? (dunno how long the door delay compares to the power delay)
Post by: Kaelem Gaen on April 13, 2010, 07:56:01 am
Was I watching for the light blue flow number? or when I could actually see flow numbers? or is there something else I'm missing?
Post by: zagibu on April 13, 2010, 05:59:15 pm
Now, if dwarven progress keeps up, they will sooner be able to simulate themselves than we humans are...
Post by: Snall on April 15, 2010, 11:07:03 am
Post by: zagibu on April 15, 2010, 12:51:41 pm
Post by: alway on April 15, 2010, 02:14:45 pm
Post by: immibis on April 15, 2010, 04:48:57 pm
Post by: Orkel on April 15, 2010, 06:45:08 pm
Post by: zagibu on April 15, 2010, 07:26:15 pm
Not possible until we can run DF on supercomputers with 16x16 (or bigger) embarks.Probably need a bit more than that. How much memory does DF eat? 1gb? 2? And how many tiles does a hydroputer memory cell need? 12? 16? Anyway, it will need a lot of tiles to map those roughly 10 billion bits.
Post by: Sphalerite on April 15, 2010, 07:31:52 pm
And considering the amount of processor power DF actually needs, I suspect your DF-in-DF computer might end up running at something less than one frame per in-game century or so. You probably wouldn't even get through world gen before the original builders all died of old age.Not possible until we can run DF on supercomputers with 16x16 (or bigger) embarks.Probably need a bit more than that. How much memory does DF eat? 1gb? 2? And how many tiles does a hydroputer memory cell need? 12? 16? Anyway, it will need a lot of tiles to map those roughly 10 billion bits.
Post by: alway on April 15, 2010, 08:44:45 pm
Post by: Meteorswarm on April 15, 2010, 08:56:54 pm
Post by: RedWarrior0 on April 15, 2010, 10:06:49 pm
Post by: Thundrim on April 15, 2010, 10:48:46 pm
( Sorry for the Capitalis Romana tendencies. But they're supposed to follow monumental creations. )
---
Post by: Quatch on April 16, 2010, 09:19:27 am
Post by: SanDiego on April 16, 2010, 09:47:13 am
Post by: Robsoie on April 16, 2010, 11:21:45 am
But this ... this is just beyond awesome, beyond the very definition of it.
Post by: Raphite1 on April 17, 2010, 12:40:51 am
Post by: Mesona on April 17, 2010, 02:13:39 am
Post by: Rastaan on April 17, 2010, 03:00:23 am
Post by: Flaede on April 17, 2010, 04:01:23 am
http://www.boingboing.net/2010/04/15/colossal-turing-mach.html (http://www.boingboing.net/2010/04/15/colossal-turing-mach.html)
Post by: Forumsdwarf on April 17, 2010, 04:05:37 am
Well done.
Is it Turing-complete? If it is I think that's a first in the history of Dwarf computing.
Edit: Yes and yes, and you published your instruction set. What do you think of these mnemonics?
Code: [Select]
000 LD
001 STO
010 ADD
011 SUB
100 JGZ
101 SHL
110 SHR
111 HALTThe only problem left seems to be the clock. It seems insurmountable, but you and your peers in the Dwarfputing community have done the impossible to get this far ...
Post by: Scruga on April 17, 2010, 04:22:10 am
Post by: style on April 17, 2010, 04:36:18 am
Post by: nac on April 21, 2010, 11:36:05 am
(http://i118.photobucket.com/albums/o120/rottingHam/Razorlength.jpg)
(http://i118.photobucket.com/albums/o120/rottingHam/razorlength1.jpg)
(http://i118.photobucket.com/albums/o120/rottingHam/razorlength2.jpg)
(http://i118.photobucket.com/albums/o120/rottingHam/razorlength3.jpg)
Post by: RedWarrior0 on April 21, 2010, 02:37:00 pm
Post by: Jong on April 22, 2010, 10:36:41 am
To think I've been ignoring the forums because I couldn't bear to abandon my fort. At least, not yet.
You know, I don't really think that being the first to build a computer in dwarf fortress is that big a deal. Of course it was a great achievement that demonstrates that you really can do anything in DF, but thats not what sustained my OCD.
What drove me was finally discovering the lowest level of function of computers and proving to myself and everyone else that computers were not magic black boxes. That's why I published my full design plans, released my save and made movies and stuff demonstrating its function. I actually felt like I completed my project once I determined the method and design to build every single component of the computer and drew up complete blueprints. After that, I felt much less obsessive and built the computer when I felt like playing DF.
My biggest takeaway is this: modern computers are simply automatic calculators of awesome power and speed. They are not magic :P
Hmm.. Let me now reply to some queries earlier in the thread.
OK, so water evaporates, right? And magma doesn't? Also, IIRC, magma doesn't mist up, right? So doesn't that make magma a better choice for computing?
It might. I considered it at the beginning, but I rejected it because magma doesn't drain like water does. Water can drain even though the tile beneath the draining tile is full because the pressure can send the water somewhere else. If I tried that with magma, the magma would probably sit there forever. You could plausibly do it by using pumps, but not in the same manner as I did for my water based system. I'll say it more explicitly: Magma computers are possible.
Another sweet Dwarfputer design!
Well done.
Is it Turing-complete? If it is I think that's a first in the history of Dwarf computing.
Edit: Yes and yes, and you published your instruction set. What do you think of these mnemonics?Code: [Select]000 LD
001 STO
010 ADD
011 SUB
100 JGZ
101 SHL
110 SHR
111 HALT
The only problem left seems to be the clock. It seems insurmountable, but you and your peers in the Dwarfputing community have done the impossible to get this far ...
Hmm.. Looks just like the ones in the source document I used to plan the architecture! Why JGZ though? How does that stand for Jump If Not Negative?
As for the clock, its not impossible to make it fully automatic. You could just simply use the repeater design more exactly. I was attempting to make a "repeater" that would only advance a step when I pull a single lever, mostly for my own convenience. The main problem is how long exactly does the computer need to stabilize its state after every operation? How soon is it safe to advance a step? Or to advance to a null step in this case. This is why I decided to just manually operate the thing.
Regarding the operation of the computer, I had this plan to build a I/O room where you could run the computer entirely by pulling levers, advancing steps, loading memory registers and such. No more running around and manually operating pumps! Then it would display the output of the accumulator and maybe even other things using spinning gears, like how some people display the results of their calculators. The whole point of that would be to make the computer usable to adventurers.
Post by: Forumsdwarf on April 23, 2010, 12:06:36 am
"Hatch off" gives you the floor's color; "Hatch on" gives you the hatch color. Could even make a segment display out of it.
Also, JGZ, oops. "Jump if Not Negative" isn't JGZ, it's JNS (Jump if Not Sign) which is pretty cryptic on a CPU without a sign flag, so, umm, JNN? :-[
Post by: Squirrelloid on April 23, 2010, 12:55:58 am
I mean, making a counter is really easy.
Post by: Pickled Tink on April 23, 2010, 01:21:47 am
But I am disappointed to say that you failed to ask the next, most dwarvenly question of all:
"How can I use this to kill something?"
Now that the computer is built you should affix it to, and program it to use, a deathtrap.
Post by: Jong on April 23, 2010, 04:48:02 am
Have you considered colored floor hatches for your primary output?
"Hatch off" gives you the floor's color; "Hatch on" gives you the hatch color. Could even make a segment display out of it.
Ah that is certainly a more compact idea! Using gears would necessitate a power supply which would be annoying to set up. Plus it would take up an extra floor.
Post by: Jyppa on April 23, 2010, 05:21:10 am
As for the clock, its not impossible to make it fully automatic. You could just simply use the repeater design more exactly. I was attempting to make a "repeater" that would only advance a step when I pull a single lever, mostly for my own convenience. The main problem is how long exactly does the computer need to stabilize its state after every operation? How soon is it safe to advance a step? Or to advance to a null step in this case. This is why I decided to just manually operate the thing.
Regarding the operation of the computer, I had this plan to build a I/O room where you could run the computer entirely by pulling levers, advancing steps, loading memory registers and such. No more running around and manually operating pumps! Then it would display the output of the accumulator and maybe even other things using spinning gears, like how some people display the results of their calculators. The whole point of that would be to make the computer usable to adventurers.
A function that executes once every lever pull (such as incrementing another repeater) looks like this: A->B->C->D->A, where A,B,C,D are pressure plates in a four-step cycle. Once built and connected to power, connect the gear controlling the pump that drains A to B to an external lever and pull it, then connect the pump draining C to D. If you want the same repeater to increment on each lever pull, connect B and D to that function. If you want constant ON signals from the different states, connect A and C. The reset time of this is simply that you can't pull the lever three times within 100 steps, meaning the limiting factor is the reset time of whatever function you're calling. You should be able to find the "safe" interval empirically.
On computer in adventurer mode, I've never gotten any fluid logic with pressure plates to work outside fortress mode, not entirely sure why. Might be impossible.
Post by: Schilcote on April 23, 2010, 12:25:21 pm
Post by: Jong on April 30, 2010, 05:04:45 am
Dwarven Computer (http://df.magmawiki.com/index.php/User:Jong/Dwarven_Computer)
Now hopefully people interested in dwarven computing don't have to be experience forum users to find my designs.
Any suggestions?
Post by: Flaede on May 03, 2010, 08:05:22 pm
I'm not sure what kind of headaches would result from trying to run it on the same map as this beast, however.
Suggestions? Wellll... all this talk of computer-fortresses running traps systems makes me think of Girl Genius' Castle Heterodyne. Anything even remotely approaching that would freak me the heck out! (This may or may not be a good thing)
Post by: Forumsdwarf on May 04, 2010, 12:44:25 pm
You should be able to find the "safe" interval empirically.Harder than it sounds, as you have to find the longest possible instruction.
If there were some way to signal completion of an instruction the computer could run asynchronously. (Not that "synchronous" isn't over-generous when talking about a clock that runs on water flowing over pressure plates.)
Post by: The Frivolous Linguist on July 11, 2010, 11:11:26 am
Post by: immibis on September 04, 2010, 06:42:33 am
We would also need to adhere to a processor standard. If we could convince Toady to compile to a simpler architecture (like MIPS, which is what I used in my hardware class), it would at least be feasible to build. Trying to build an x86 processor would probably only end in sadness.Or write an x86 emulator in MIPS.
Post by: Medicine Man on September 04, 2010, 08:18:03 am
Post by: AUTOMATIC on September 04, 2010, 03:07:09 pm
Post by: Comrade_Fregge on September 16, 2010, 04:00:38 pm
Post by: Bronimin on September 17, 2010, 12:27:25 pm
Post by: Diacritic on September 17, 2010, 02:03:37 pm
You should have implemented one instruction set computer, way more elegant than this 8 instruction one.
There's always one of these, isn't there?
Post by: rodomir on February 08, 2011, 11:59:01 pm
There are no words strong enough to congratulate Jong.
The internet has been won
Post by: franti on July 15, 2011, 05:40:27 pm
Post by: Urist_McArathos on July 16, 2011, 12:00:11 am
This is so epic. Make a DF computer so complex you can play DF on it.
This would likely require a site larger than the largest possible embark at the moment, AND a single-core processor that was immensely more powerful than anything currently in existence, or (given the state of developing multi cores), anything that WILL be in existence for some time.
In other words, it's the most dwarfy IRL project imaginable. Ergo, it must be done. Urist! Fetch my soldering iron!
Post by: mstram on September 25, 2011, 12:53:53 am
I finally got around to wikifying my computer design.
Dwarven Computer (http://df.magmawiki.com/index.php/User:Jong/Dwarven_Computer)
Now hopefully people interested in dwarven computing don't have to be experience forum users to find my designs.
Any suggestions?
Yeah, they just need to be experienced D.F. users ;)
I just started using the program today, and am stumbling my way through the docs /tutorials etc.
I've copied your "region2" folder inside D:\Dwarf Fortress\Game\data\save.
When I start the game, I see Amethadefini, is available, and I select it.
Then I get to the "pre embark" screen.
Where is /are the fortress(es) / computer ? on the grid ?
I tried selecting the whole grid, but that just killed my p.c., so I started looking in 4x4 chunks, but that seems a silly thing to do.
I started the "Object Testing Arena", and it seems there is computer-looking-stuff in there, but I haven't figured out how to use the arena thing yet.
So how do you actually run the "computer" ?
thx
Mike
Post by: mstram on September 25, 2011, 04:31:06 pm
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.
Hi Jong,
Where on the "region map" are the memory cells ?
It would be helpful if you added a short tutorial to the wiki, on how to change the memory cells / run a program.
Or is the cpu continually running, and when the memory cells are changed, the program (of course), just changes "instantly" (heh, read your comment about "a month in sim time to execute a few instructions)
Mike
Post by: Jong on September 25, 2011, 05:13:51 pm
While I appreciate your interest, this thread is quite old. I'm pretty sure that most of your troubles stem from the fact that you have loaded the save in the latest version of DF, while the computer was built in version 40d.
A successful load will bring you straight into fortress sim mode, rather than the pre embark screen. Following that... well as you said, I sort of assumed that anyone interested in the computer would have some experience in DF. If you want to learn to play DF, you probably should avoid loading up mature forts like this one as you would be easily overwhelmed. If you just want to see the computer working for yourself, then you can PM me again and I'll try to help you along.
Post by: yatsun09 on July 24, 2013, 10:59:42 am
Post by: wierd on July 24, 2013, 03:10:48 pm
I posted the wiring diagram for the MOS6502 in the abacus thread earlier. It's simple enough that it should be possible to implement with minecart logic gates.
Adding a 1bit color 2d output array (raising bridges in a sealed room), and some form of input device, you should be able to run arbitrary programs, as long as they fit in memory.
Post by: mstram on January 12, 2014, 10:41:15 am
One of the main tools lacking in DF 40d is the ability to show what is linked to a lever.
I'm looking through the mod section/ DFFD now, looking for tools that can help to document / explore this project.
Post by: mstram on January 22, 2014, 05:58:35 am
Well now with the aid of the dfhack 04d tools, it is getting a bit (heh) easier to debug this thing.
I'm trying to figure out how the registers screw pumps are activated on the "bit-level".
I see the links between the computer-clock's pressure plates and the gears.
And I see where the gears connect to axles that are adjacent to all the pumps in a register.
But how does an individual pump, in a register get activated ?
Mike