User:Larix/MPL/3

Dedicated devices

As with other alternative logic disciplines, MPL is in many ways inferior to mechanical logic when it comes to the actual logic gates. Mechanical logic performs nearly instantaneously and requires little space. It's also a lot easier to run multiple mechanical operations off a single switch by running power through "master gears", while in MPL you have to individually connect every single device to every desired signal source. Mechanical logic, however, is not capable of generating signals by itself, of lasting data storage and incrementation ("counting") - the only "output" of mechanical logic is transfer of power and all states of mechanisms directly reflect the state of inputs, they cannot hold a "memory state" while input changes. Alternative logic types are required to generate and store signals. For counting, for repeating signals and to implement "memory", your options are fluids and minecarts, and MPL is an attractive choice here, because it's naturally liquid-less and can be implemented without use of power.

This is only a selection of MPL circuits i've built. They're mostly custom-made on the spot when i had the need for a circuit to perform a specific operation. Once again, they were practically applied, these are not theoretical "this should work because the logic is sound" circuits, i even built and tested the straight Set/Reset latch which could not conceivably fail. I've had too many cases of the inconceivable happening with minecarts.

Counter

For speed regulation and cart management, there are a bump wall and bunker pit to the east. The operational unit is the angled three-pit ramp in the middle. The ramps are engraved with track like this:

   ║
  =╠

When the hatch cover is open, a cart coming from the west will pass through to the east, one from the north will pass through to the south. If the hatch cover is closed, a cart coming either from the west or from the north will exit to the north. Thus, the procession of operation when counting is:

1. cart enters the circuit on the outer ring, entering the three-ramp pit from the west.

2. as long as the hatch cover remains open, the cart will pass the ramp West->East, gets regulated by the bunker pit and remains circling around the outer ring.

3. once the hatch cover closes, the cart is diverted to the north and starts bouncing between the bump wall and the closed hatch cover.

4. once the hatch cover opens again, the cart passes through the pit to the south and leaves the counter circuit, e.g. entering the next one in the line.

A series of such counters, arranged in a circle, can be operated from a single input signal connected to all hatch covers and will thus count how often this input has cycled. The reaction time to a changed signal is fairly long, up to 50 steps, so the input shouldn't cycle too quickly, or signals will get missed.

It is easy enough to glue two of these counters together and have a pressure plate on the connecting track, so it sends a signal of its own after every second advancement. This is in effect a binary counter, and combining several of these allows to perform binary addition and subtraction.

Luxury one-bit memory/counter

This is a binary counter cell which can add and subtract, and can also be set to one or zero. In the adder/subtractor design i came up with, the "memory" is the part which performs the actual calculations, directed by signals sent from another circuit "reading" the input. All carry calculations are done in the counter/result memory itself and additions are performed from highest to lowest bit.

The device consists of two counters, linked through a northern and a southern loop. When the central hatch cover in the cart's current half of the cell opens, it passes through the loop to the other half. If the hatch in the pit on the loop is open, the cart passes through without further effects, if the hatch is closed, the cart is sent on the "inner" branch of the switchover loop and touches a pressure plate which sends the carry (south sends negative/subtractive, north sends positive/additive carries) to the next higher bit. If both operative hatches are opened, the memory cell's status will change to the opposite; depending on further hatches opened or not, this may generate carries and work as addition or subtraction. If only one operative hatch is opened, together with the hatch in the resultant switchover loop, the cell's value is "set" to a specific value - if the cart was already on the desired side of the cell, nothing changes, obviously.

The full installation shown here makes for a very component-expensive bit of memory. Its benefit is that it allows a lot of operations on the memory directly. With four different-weight carts, sending input to the cell through pressure plates with three different weight ranges sending different signal combinations, i could run, on the same memory array, addition, subtraction, "write" (i.e. setting the memory to a desired value) and bitwise XOR (addition without carry). The memory itself is static - bits are represented as a "held" on signal, deriving independent on-off cycles would need an extra "converter" unit for each bit. In my four-function application, one bit took four hatch covers, three pressure plates and seventeen linkages, not even counting the input regulator and any possibly more complicated output machinery, for a cool 37+ mechanisms per bit. Its multi-purpose functionality makes it an interesting option for a "result" or "arithmetic" register, much less so for a plain memory bank that's only supposed to store and not directly manipulate data.

Bridge Repeater

A curiosity, a powerless repeater sending a signal every ~205 steps which can be used to operate a constantly opening and closing bridge. The only operational pit is the one to the north, a looped-ramp pit (ramps SW and NW) with the northern ramp covered with a hatch cover linked to the output plate. As long as the hatch cover is open, the cart will cycle through the pit and the flat half-circle directly west of it. Once the hatch closes - one hundred steps after the cart went over the pressure plate - the cart will pass over the hatch, bump into the wall and move incredibly slowly to the south, fall into the bunker pit, leave at a slightly more sustainable speed and touch the plate again.

Double-action switch

An "edge detector" or, more simply put, a device to convert lever pulls into single on-and-off signals. The cart starts out on the hatch to the west, over the eastern ramp of a bunker pit. Once the input signal turns on, both hatches open, the cart falls into the pit, cannot leave to the west and thus leaves to the east, across the pressure plate and starts circling through the loop to the east until the hatches close again, when the cart will return from the pit to the north, pass the pressure plate again and bump against the wall to the west, coming to rest on the starting hatch cover again.

Alternatively, the hatch cover to the east can be operated by a different signal and a pressure plate placed upon the loop the cart will circle through. When receiving e.g. a "pulse" signal (i.e. an "on" followed shortly after by an "off", a common occurence when working with pressure plates), the cart will now generate a secondary "on" signal and will, by circulating over the pressure plate, keep the plate activated and thus whatever was activated by the signal constantly in the "on" state, even if the priming signal has turned off again. Only after a separate "off" signal is sent to the hatch in the loop will the cart stop circulating and allow the pressure plate to reset. This is, i believe, the basic function of a latch.

Auto-derailer

A device i used quite a lot in my first designs. The ramps are engraved with NW and SW track. The cart will cycle through the array, generally emerging on the northern track tile, cycling around to the south and entering the ramp again. It will keep accelerating until it becomes fast enough to derail. If there is open track to the north of the northern ramp on the level below, the cart will leave the array to the north at this point. Depending on the starting conditions, the cart can take anywhere from ten to 350 steps before leaving the derailer. If the cart is kept in the derailer, e.g. by blocking the exit path with a door, the cart will not accelerate notably beyond the original derail speed, it will just be kept within the array at derail-capable speed.

Clock-capable repeaters

The visible ramp openings belong to looped pits, engraved SE-SW on the southern branch, NW-NE on the northern branch, with the second pit covered by the straight track leading out of the niches. The track stops on the exit points have high friction, the track stop just south of the northeastern ramp has low friction, all others medium friction. The return time is exactly 300 steps, 1/4 of a DF day. Collecting a single signal and plugging it into a four-step counter will give a full day.

These are actually four repeaters, three of which are used to run a precise clock. Each repeater consists of two derailers, coupled like this below:

There's a medium-friction track stop on each connection track, the final tile, under the pressure plate, is a corner sending the cart onto the "backwards" ramp of the partnered derailer. This results in the cart being so fast on entry that it derails over the ramp pit, slams into the wall and falls down onto the "forward" ramp. This greatly increases the time required to build up to derail speed, giving a full return time of 720 steps for each repeater. I started three of these repeaters 240 steps apart, so every 240 steps one "full round" signal is received and can be counted, five of them add up to a full day.

Memory

Minecarts can be held in a loop or on a straight rail just going back and forth by hatches and other buildings. By combining "data" and "enable" or "reset" buildings on the same circuit, all with their own links, this can be used to store data in an adressable form.

1. Basic Set/Re-set latch

.

#

▼

║

▼

║

¢

s

¢

s

║

#

║

+

e

▼

║

¢

r

¢

r

▼

║

▼

║

#

^

▲

#

1

2

3

4

.

1. Track/ramps

2. engraved track on the ramps in the pits

3. buildings

4. space-saving expansion using a door to "e"nable the cell, designed by Nil Eyeglazed/VasilN.

In the "off" state, the cart remains in the northern ramp-pit, because its exit is blocked by the closed hatch to the south.

If a "set" signal is received (and in the expansion, if the "enable" door is opened as well), the cart leaves the northern pit, jumps across the southern pit, bumps into the wall, gets reflected by the ramp and settles into the southern pit, bouncing between the hatch cover blocking exit to the north and the ramp above to the south, keeping the pressure plate activated. Further "set" signals will not do anything.

If a "reset" signal arrives (once again, only respected if "enable" is also set in the expansion), the cart leaves the southern half of the array, travels north and settles into the northern pit, letting the pressure plate reset and thus dropping the saved bit. Additional reset signals, once again, will not change the memory state.

As usual in Set/Reset-latches, a currently-on cell will not react to changes of the "set" signal and vice versa, the memory cell will hold the saved state indefinitely if both inputs remain off and it will produce an erroneous output (false "on" in this case) if both signals are on simultaneously.

The possibility to "adress" this memory can be realised in different ways and a further non-destructive "read-out" producing a signal cycle instead of the constantly-held "on" can be provided just by adding another pit to the south. It is a very compact design and can be packed extremely tightly: with an extra read-out, it comes to a length of eleven tiles, while it's two z-levels high and a single tile wide. Neighbouring memory cells can share a wall tile, so each past the first will only take ten tiles of added length. Materials required come to one door and three hatch covers with four linkages among them for input and at least one pressure plate and one linkage for output - four furniture and eleven mechanisms.

2. Spin Memory

This one's more of a plaything, more remarkable for its style than for practicality. I used it to build a sample adressable memory and it works reliably, if quirkily. Building a large minecart memory would still be better done by building the above memory cells and adjusting them for easier adressing.

╔

╗

╔

╗

▼

╔

╗

D

¢

╔

╗

#

▼

║

▼

╗

E

¢

║

¢

R

║

╚

▼

║

A

^

▼

║

╚

═

╚

╝

╚

═

╚

^

B

P

a

t

h

s

B

u

i

l

d

i

n

g

s

All ramps are engraved with NS track.

In the "passive" state, the cart rests on top of the "E"nable hatch. If this hatch is opened, the cart falls into the pit and leaves it either to the north or to the south, depending on whether or not the "D"ata input is on or off. It will then make its way to the eastern ramp-pit, either onto the southeastern or the northwestern half-loop. If both access ramps were open, the cart would constantly cycle through this pit, remaining in the same half-loop forever.

In the given architecture, however, the cart will only establish a stable cycle if the Data input was "on" and the cart went onto the northwestern loop, because the "signal" pressure plate at A is linked to the hatch cover at "R" and keeps it open. Pressure plate B is not linked like that, so the cart will pass over the still-closed hatch cover at R and returns to the enable hatch cover at E.

E must be operated through a signal cycle of calibrated length, not through a lever; when the Data input is off, the returning cart must reach E when it is already closed, so it properly stops on top of the hatch again. If the hatch closes over a cart in the pit, the cart will be caught and will spontaneously re-activate upon any "on" signal received by the enable or data input, generating garbage data - and possibly ending up caught in the pit again.

A cycling "on" cart can keep a linked building constantly activated, but to read the information back to a data collector, an individual signal must be triggered. To achieve this, a signal cycle is sent to the "R"eset/read/clear hatch. After the signal times out, the hatch cover will close again, the cart is reflected out of the pit onto the southeastern loop, touches the pressure plate there and returns to the "E"nable hatch. This signal can be read and stored by a different memory cell.

Activation while the data input is off will send a "fake" signal cycle output. Triggering a read of the cell requires an on/off cycle, resulting in a minimum latency of 100 steps, and destroys the read datum. This cycle must be sent to each cell individually that's supposed to be read/reset. Consequently, the processing and control of this kind of memory is quite complicated. It takes three hatch covers to build, with four connections between them, and two pressure plates, one with an actual output link - twelve mechanisms. Space consumption is 4x9 tiles over two z-levels per bit pair if constructed in the tightest possible mesh, 4x5+1 on two z-levels for an isolated cell.

While inferior to the straight-line latch above, the principle of this stable-speed loop can be used for a smaller design of the edge detector/double-action switch above.

Mini-Excursus: Material costs of different memory designs

Let's compare: the minimal mechanical-to-minecart memory cell (Bloodbeard's design) takes two minecarts, a weight-calibrated pressure plate connected to output, two rollers, each with an own switchable gear assembly to either set or reset and some drive train. That's eleven mechanisms, not counting the drive train, which can be shared with other cells. A single added "enable" gate would add another gear assembly and link, bringing mechanism count to fourteen. And it still would need a dedicated extra circuit or some kind of extension to read memory state as an on-off signal cycle. Where the powered design wins is in space consumption - can be condensed to 2,5x4 tiles on a single level - and in response time and uniformity: Bloodbeard's/TinyPirate's designs reach "finished" state after a signal in about five steps with maybe one step variation due to build order, vs. the much longer and variabler times of MPL memory: 10-35 steps from "set" signal to "on" state or 2-30 steps from a "read" signal to providing the output.

A fluid memory cell can be simplistically made with two doors and an output pressure plate, costing seven mechanisms for either a simple set-reset cell or a cell that takes on the state of a "data" input whenever it's adressed. In the latter case, some fiddling with raising bridges would also be possible, running up to five cells off a single "input bridge". Once again, such memory would be fairly static and it'd waste huge amounts of water in operation.

Verdict? Hmm, memory in DF takes ridiculous effort and material. No wonder we haven't built a full 16-Bit computer yet, even the 16K of memory of a cut-rate ZX Spectrum would run up a cost of about 700.000 mechanisms if built as the crudest possible low-functionality latches. Even a single kilobyte of memory would be in the range of the biggest dwarfputing megaprojects ever built, and could easily top them if any sort of advanced memory functionality was included. I do have an idea for a dwarven mass storage device, though, which could probably handle a kilobyte with a few hundred mechanisms. The main cost would be something else...

The relative expensiveness of DF memory suggests, as has been good dwarfputing practice, not to strive for computing projects that call for large amounts of memory (i think that's what eventually caused Bloodbeard's excellent input processor/pattern collector to stall) but rather invent clever machines that can do interesting stuff with little memory. And, as the wiki page on memory states, the best memory design is the one that best fits your specifications. I'd say what you're going to use primarily comes down to the general features of the various logic disciplines, not so much the way memory works in them: fluid logic can be very sparing in machine parts required, while mechanical logic is very reconfigurable and fast and pure minecart logic relatively quick to set up and maintain. On the downside, providing the liquids for fluid logic to work with can be a hassle and fluid logic circuits tend to be difficult to maintain once operation started. Mechanical logic absolutely requires power, can become quite intransparent very quickly and hinges on a single main labour with little other application in the fort. Minecart logic is quite a bit slower in its reactions than mechanical logic, takes a significant amount of space and machinery, exploits bugs and is notoriously dangerous to your dwarfs. I have no experience of creature logic, so cannot commment on it.

End Excursus.

Size-optimised incrementer

Since i had such success miniaturising powered minecart incrementers/counters, i tried my hand at a powerless version. This variant reacts only to "off" signals.

.

#

▲

▼

║

╗

▲

¢

A

╚

▼

╚

║

a

^

▼

║

^

c

▼

╗

║

╗

▼

^

b

▼

▲

╚

║

B

¢

▲

#

F

l

o

r

,

T

r

a

c

k

H

a

t

c

h

e

s

,

R

a

m

p

s

P

r

e

s

u

r

e

p

l

a

t

e

s

.

Pressure plates a and b are linked to the respective hatch covers A and B, but the hatch covers are also operated by the input that shall be counted.

As long as the hatch cover remains open, the cart will stay in a four-tile circuit, with a circulation period of twelve steps. When the input is cycled, the "open" signal will be ignored, since the hatch of the pit through which the cart cycles is already open, but the connected "off" signal forces it closed. This sends the cart out through the straight ramp, over the straight track and into the top-level part of the other half-loop, where it first bounces against the upward ramp, rolls off it and gets sent into the ramped pit by the corner tile, once again establishing a stable circuit because it touches the pressure plate and opens that loop's hatch cover.

A "carry-out" pressure plate is included at position "c", which gets activated on every second counting event.

Since it only reacts to "off" signals, this incrementer works with notable latency, especially when several of them are linked in sequence for a binary count. Other incrementers send their output carry as reaction to an "on" signal. Powerless designs that react like this are bound to be a bit larger; the three-ramp pit above should already be a decent option for that purpose. That design can be made more compact than the shown examples and only needs one single-linked hatch cover per counting unit, two hatches without any internal connections if installed as a simple bitwise incrementer.