A were-gopher showed up and ate the freshly minted legendary mason (member of the starting seven) before the military could catch up with it. The two legendaries dealt with the problem in a very convincing fashion: chopped off an arm first, then the hammerlady scored a hit to the neck that disabled all limbs and the axelord finished the fight by removing the head. The secondary squad has started sparring, so they're shaping up alright. Two gigantic humanoids and one were-beast so far, the most trouble we had with buzzard invasions. "Yes yes, interrupted by a featherball, shut up and work out how to use your damn crossbows, you bunch of loons."
Yep, dwarven computing again. Memory's been a major hindrance in building useful dwarven computers. The more common memory cells take anywhere from fifteen to thirty mechanisms for a single (read-writeable) bit, counting adressing devices, means to read the state etc. Some memory designs, however, are fairly cheap in mechanisms and can be optimised for low counts:
the smallest memory cell i could come up with that actually holds a signal (there are options with stored minecarts off pressure plates, but those are not very writeable) is the fluid logic Data Latch:
.####
~DE^#
.####
D - data input (which value the cell is supposed to have)
E - enable - operated through adress logic, lets the cell take on the state of the Data input.
^ - pressure plate calibrated to activate on 5-7 fluid.
Can be run with magma, but water is easier: for bulk processing, you need pressurised fluid with an infinite supply.
Now that's already fairly cheap in mechanisms, taking one connection each for data and enable input and a mechanism and one linkage to get a meaningful output, seven mechanisms. But if you have several "registers" working off the same data input, you can just collect them:
B###
BE^#
B###
BE^#
B###
BE^#
B###
B - a single bridge, raising E, stretching at least seven tiles N-S, operated by the collective data input.
E - Enable doors (each separately run for each register)
This reduces per-bit mechanism count significantly, since we only need one linkage to operate the bridge that represents the data input. Up to twelve cells(*) can share a bridge (water must be supplied from above, preferably pressurised). That leaves us with one enable input and one pressure plate output per cell, and 1/12 of the "linking cost" of the bridge. Should come out a bit below six mechanisms per bit.
(*) on a single level. At the cost of fiddling around with vertical architecture and making the design much uglier, you could have 17 cells sharing each input, burning 9 tiles of water when the bridge raises and between one and two when a cell is written to.
The remaining issues are
1. bridges crush water
2. bridges take a while to react to signals
3. output is still a "static" signal - pressure plate is on or off, and if you have multiple registers that can all send their values to a shared output, immediate state there will always be that of the last received signal. You'll still need to convert the memory cell's state into an active on or off signal to successfully read it.
4. the cell will be filled when reading a data input in the "off" state, at low water when reading an input that's "on". The more reliable "on" state of such cells is the filled one, which under this logic actually corresponds with the "off" state.
1. and 2. can't be circumvented. This memory cell design depends on water-crushing and the shared data input can only get that wide with bridges (you could feed four or maybe five cells off one door).
For 3., i took a page from real-world computing: destructive reads. If we write the exact same data value to all cells of a register, only the cells that were previously in the opposite state will change and send a signal. Then all we need to do is set our "memory reader" into the proper starting state before we "read" our memory cells and we get the proper output.
We'll probably also want to feed this read-out right back into our register, to restore its state.
I won't show pictures, the actual logic is conceptual anyway. The important part is the "read cycle":
I'm using minecart set/reset latches to store the read data.
1. Cycle all "set" inputs (on-off signal cycle, using hatch covers to regulate sets, turns all bits of the latch on, closes all set hatches in 100 steps)
2. Reset the latches via on-off cycle to the "reset" hatches. All bits turn off, all reset hatches are closed after 100 steps.
1a. Cycle the data input bridges, if necessary. If your inputs come through periodic activity anyway and the bridges are normally lowered, this is not necessary. The bridge cycle can be sent when the set inputs are cycled, the events don't interfere with each other.
3. Write to the adressed register. This sends "zero" to all cells of the register, filling them with water. All cells that were previously full of water remain full and their pressure plates remain activated, thus no signals are sent. All cells that were previously empty/low are now filled with water and their pressure plates send an "on" signal, opening the "set" hatches in our reading latch. This incidentally solves problem 4. above (quasi-reverse logic of input/cell state when using a raising bridge as data input). The latch is now in the state the register had previously stored, the register is empty.
4. read the latch's state, e.g. by opening access to a short measuring track - when carts are in the "active zone", they pass over the output pressure plate, carts from bits that are "off" will normally sit still on top of the closed setting hatches.
5. write the latch state back into the source register. This takes a while, because you need to wait for bridges to respond/raise before the new values actually take. The pressure plates in register cells that receive an "on" (raised bridge) will have low water and their pressure plates turn off, closing the set hatches in the latch: you don't need to cycle the set hatches between consecutive reads, only if the last memory operation was a write.
The one-off costs for the reading machinery are substantial, the whole thing must be fairly big (well over 100 bits) to really pay off. There's a mandatory cost of five mechanisms to link the enable door and pressure plate in every cell, but all other machinery could boil down to one and a half mechanism per bit, for six and a half per bit total. Not exactly cheap, but about half of what most other designs require. It also takes a pretty long time to read, from just over 200 for a simple read without restoring the register state to about 600 when several pieces of furniture need cycling and the values in memory are to be restored.
This concept is practically proven, i built a small testing rig of five three-bit registers running off three bridges, with single-signal read and write operation.
Author
Topic: What's going on in your fort? (Read 5844204 times)