A thread on stackexchange got some wheels turning again and of course the solution was quite simple when not thinking in logic gates:
if you want to calculate the binary complement, the easiest way in DF logic is to just look at the lowest bit that's set and toggle every bit that's higher. In dwarven logic, that can be done as a fairly trivial single-pass check.
Fast, power-hungry:
PA=s1
|
A'B=s2
|
B'C=s3
|
C'D=s4
|
D'E=s5
|
P - Power, offered only here!
A gear assembly linked to be engaged when signal A is on
A' - gear assembly engaged when signal A is off
B/B' etc. same for signals B etc.
Since power propagates down the line as long as an unbroken chain of off signals is found and at the first "on" signal breaks the chain, generating a "s"ignal instead, you get an unambiguous signal from the lowest set bit, nothing else. All that needs doing from here is convert this information into toggle signals, which once again isn't overly difficult - have single power source coming in from the _highest_ bit and let it trickle down a single-thread chain that can be broken (disengaged) at the appropriate points, unpowering the entire lower part of the power chain without needing more than a single switched gear for each setting. Bloodbeard's/tinypirate's powered memory cell is quite convenient for a powered toggle:
# #
║ R*
║ ^
║ ^
║ R*
# #
R - roller
^ - pressure plate reacts to minecarts, linked to disengage gear assembly powering the roller next to the plate
Two minecarts required, one must sit on a roller, the other on the "opposite" pressure plate. When power is provided, the cart is pushed along the track, reaches the adjacent pressure plate, pushes the other cart off the other pressure plate and onto the opposing roller. Only one roller may be powered at a time.
Offering a 100-step power pulse to _both_ gear assemblies toggles the cell - the gear assembly of the "deactivated" signal remains disengaged for 100 steps after the cart has been pushed.
This can be combined with a fully and independently settable memory array, but takes a lot of machinery, since you need to make sure you don't accidentally power rollers through the opposite power trunk. Time between operations can be as short as 115 steps.
Powerless, simple, slow:
╚╗ B^
╚╗ B^
╚╗ B^
╚╗ B^
B- bridge toggled by signal
^- pressure plate toggling the lowest appropriate bit (one higher than the bit operating the adjacent bridge)
One cart is sent through from north to south, keeps moving in a straight line until reaching the _first_ bridge operated by a set bit, branches to the east there and passes over all pressure plates toggling bits higher than the lowest set one. Suggests use of a powerless togglable cell. Time between operations significantly over 230 steps (must wait for memory content to settle and bridges to reset).
Powerless write- and toggle-able memory cell; yet another refinement of stuff i'd been using:
z+1 z+0
##### #####
##▲## #####
#╔╬╗# #####
#║▼║# ##║##
#▼˘╝# #═╠##
##╔╝# #####
##+## #####
##˘## ##║##
##G## ##║##
##### #####
All track on z+0 is on ramps. The "up" ramp on z+1 has NS track and touches a wall to bounce back carts coming from the pit to the south.
˘ - hatch cover, operated through signal
G - floor grate
+ - smooth floor, no track
The hatch cover to the north and the floor grate are operated through the "off" signal, the hatch cover to the south through the "on" signal. All are operated by a "pulsed" toggle signal (plate passed once by a minecart or the like, not a lever that's only operated once and left in the oppsite state).
If the cart is in the north, it either cycles through the angled pit west-to-east and around the northern loop when the hatch cover is open, or bounces between hatch cover and northern upward ramp if the hatch is closed. Once the hatch opens _again_, the cart leaves to the south, jumps off the plain floor across the southern hatch cover and lands on top of the floor grate. The floor grate opens 100 steps after the hatch cover(s) and dumps the cart into the pit. If it came here through a "write off" signal, the southern hatch cover will be closed anyway, if it arrived through a toggle, the connected "off" from the signal "pulse" means the hatches close at almost the moment that the grate opens, so the cart cannot leave because the hatch has closed again before the cart reaches it. The non-track floor directly north of the southern pit also makes sure that the cart doesn't enter the pit but rather jumps over it even when the hatch is open.
That's not idle speculation, i've built and carefully tested this design and it works. The main issue is that switching to "on" (i.e. sending the cart up north) is a bit wonky, the first cycle is extremely slow, but not slow enough to cause output signal flickering, so it all works out. (I suspect the cart ends up banging against the wall in the pit, stops and re-starts just barely "up" the ramp, so collects extremely little speed on the remaining acceleration stretch.)
This design can be modularised quite a bit - only three of the surrounding wall tiles should be truly essential, so sticking such cells together could presumably result in a densest packing of 3x6,5 tiles on two levels per cell (less than half of the 5x10 shown). It only produces an output in one of the cell states and reading to a bus-like system would have to be done externally, because its output is quasi-permanent.
Author
Topic: What's going on in your fort? (Read 6223722 times)