Editing User:Larix/MPL/3


'''Advanced circuits'''


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===

[[File:Zählwerk mit Bauten.png]]

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 counting.

===Luxury one-bit memory/counter===

[[File:Rechner-Speicher-Zelle.png]]

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. I built cells of this type taking four different input configurations allowing it to run addition, subtraction, "write" (i.e. setting the memory to a desired value) and bitwise XOR (addition without carry). The memory itself produces a permanently "held" ''on'' signal as output, deriving independent ''on-off'' cycles would need extra "converter" units or destructive reading. 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===

[[File:Brückentakter.png]]

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 closed, 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===

[[File:Kippschalter.png]]

An "edge detector" or, more simply put, a device to convert lever pulls into single on-and-off signal cycles. 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.

===Auto-derailer===

[[File:Und-Gatter ohne.png]]

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.

The main interest in the basic circuit is that it can be used to introduce a significant delay into a circuit, without moving parts and with very low space consumption.

===Clock-capable repeaters===

[[File:UhrwerkBremsen.png]]

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.

[[File:DieUhr1.png]]

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:

[[File:DieUhr2.png]]

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.

{{Diagram|spaces=yes|\
.
    ^╗         ╔╗
    ║▲#        ║╚#
  #▲╝║▲#     #╗╝║╔#
  #▲══▲#     #═║║═#
  #▲║╔▲#     #╝║╔╚#
   #▲║        #╗║
    ╚╝         ╚╝

Buildings    Track

}} 

A clock-capable repeater with a period of 600 steps - half a day. In the two "combs" of three ramps each on the eastern and western side, the cart bounces between the two border ramps and is displaced by 1/29th of a ramp's width everytime it passes the middle tile. After 29 passages (about 290 steps), it is displaced far enough to make it off the comb and into the switchover loop. All ramps are impulse ramps - the bordering ramps mustn't offer exits to above or the cart will just climb the ramps and disappear onto the level above. 

===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

{{diagram|spaces=yes|\
.                 
  #   #   #    #   
  ▼   ║   ▼    ▼   
  ▼   ║   ¢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. Adding dedicated "read" branches

{{diagram|spaces=yes|\
.
  #    #
  ▲    ▲
  ^    ║
  ¢o-  ▼
  ▼    ▼
  ║    ║
  ▼    ▼
  ¢s   ▼
  ┼e   ║
  ¢r   ▼
  ▼    ▼
  ║    ║
  ▼    ▼
  ¢o+  ▼
  ^    ║
  ▲    ▲
  #    #

}}

I implemented the main memory of my dwarven computer with this type of memory cell. It can be set (via the "s" hatch) or reset (via "r") as long as the cell is selected ("e"nabled). It will not normally produce any output unless specifically requested by opening the "o"utput hatches. For reasons of functionality, it has two output hatches and pressure plates and can thus generate separate output signals depending on whether the cell is currently in set or reset state. 

A major downside of this design is the duration of the output signals: the cart will start activating the pressure plate shortly after the hatch opens and will keep passing over the plate until the hatch closes again, after about 100 steps. Only 100 steps after the cart last touched the plate will the plate reset and send its off signal. The result is a signal remanence of about 200 steps. Such delays can easily stack up in cascaded logical processes, jeopardising the practicality of usage through excessively long signals.

3. Short-pulse memory cells

{{diagram|spaces=yes|\

   #   #   #     #       #
   #   ║   #     #       ║
  a¢   ║  a¢    a¢       ║
  c+   ║  b┼    b┼       ║
  b¢   ║  c¢    c¢       ║
  ╔▼  ╔║   ▼     ▼══╗    ║══╗
  ║+d ║║   ║    d┼ ║╝    ║ ║╝
  ║^  ║║   ▼     ^▲▲▲    ╚╔║╗
  ▼╗  ║╗  d¢      ###     ###
 e¢▲# ╚║#  ^     III.a   III.b
  ##  ##   ▼
  I.a I.b  ☺
          eG
           #
           #
           II.

}}

To adress the concerns pointed out above, i developed a few memory cell designs that will only send one short-term signal pulse. To achieve this, the cart must be delayed until the output request has timed out and then sent back to its memory holding location on a path that bypasses the pressure plate. 

Key for all cells:
a - set
b - reset
c - enable

d - request for an output
e - building that moderates the delay for returning the cart

I.: building-moderated delay, lateral bypass

d & e are activated by the read signal: the door lets a "set" cart out of its pit. It passes over the pressure plate ''once'' and then cycles through the four-tile circle in the very south; the cart must come in at the correct speed for the orbit to properly establish and remain stable. Once hatch e closes again, the cart leaves straight to the north (instead of SE while circling) and returns to the "set" pit. 

II.: building-moderated, vertical bypass

Instead of keeping the cart in motion until the read signal turns off, this design makes use of the different delays for different buildings. In the south, there's a floor grate over a bunker pit. When a read is performed, an "on" cart leaves its pit to the south, touches the pressure plate and comes to rest on the grate. The grate takes 100 steps to open. At this point, the cart drops into the pit, picks up speed and leaves to the north. Immediately north of the grate, it passes over a tile of ordinary floor (here engraved with a friendly face) before facing a pit. Since it comes from normal floor, the cart ignores the pit (has no downward connection and wouldn't change the cart's speed in any way) and jumps instead. The jump is far enough that the cart passes over the pressure plate north of the pit without touching it. The assumption is that by this time the actual read signal has timed out again and the read hatch is already closed, keeping the cart constrained in the holding pit.

III.: path-moderated, lateral bypass

Of course, we can also give a cart enough path that it takes 100+ steps to return to the holding pit (assuming the read request is produced by a short-term signal that shuts the requesting building after about 100 steps). It uses the same "ramp comb" as the third model of a clock repeater. The sole difference is that the corner at the entrance to the array ensures that the cart enters it in the middle of the tile, so that it takes only 15 passes over the central displacement ramp to exit the array, giving a total return delay of about 160 steps. 

All designs have been tested and work. They're all notably bigger and clunkier than the simple straight designs shown above and are only worth the effort when the well-regulated short output signal is desired.

''If'' timing is crucial, these and similar approaches become mandatory, since they limit the necessary "cooldown" time until the next signal can be processed to significantly under 200 steps, while especially in long cascading approaches the above "cumulative remanence" designs can quickly escalate out of control. 

Similar and better timing for reading stored information is possible with fluid-mechanical logic, at the price of power consumption.

4. One-building toggle memory cell

{{Diagram|spaces=yes|\
.
     ###
    ╔▲▲▲
    ║ ║╗
    ║ ╔╝
 ╔══┼▼▼^▲#
#▲  ▼ 
#▲═╔▼
#▲╚╝#
}}

The cart's in one of the double-ramp pits when the door is closed. Whenever the door opens, the cart leaves its pit, goes through a ramp comb starting in the middle of the tile and enters the other double-ramp pit of the array after ~160 steps. As long as the door is opened by short-duration signals, the cart will properly settle into the opposite state after each signal received. 

===Mini-Excursus: Material costs of memory===

For me, the crux of building advanced logic machines is the extreme cost of memory. 

The memory designs seen here range from two hatches and one pressure plate for the non-enabled S/R latch (five mechanisms not counting output links) to seven buildings (with fourteen mechanisms for links) and two pressure plates for an enabled cell with bidirectional outputs and hatch-moderated holding/lateral bypass. As an even more extreme case, the big complicated count-capable memory cell at the start clocks in at over thirty mechanisms. 

Looking at other designs, fluid-logic data latches can be operated with a single door for enabling and a large shared bridge as data input (serving up to twelve cells). Actually reading the cells tends to become a bit complicated but can be done at lowish mechanism cost if rather slowly through destructive reading (set a cell to a given state and test if output ''changes''). Cost per bit stored in a full installation would be just under six mechanisms and one door. Similar designs are possible with MPL, although they are slightly costlier in mechanisms and space and are somewhat slower. 

The "cart placement" memory cells developed by Bloodbeard and tinypirate come at costs of ten to fifteen mechanisms per bit, depending on the functionality included in the cell. They'd also require either a very costly big reading array or destructive reads.

All these reasonably write-able memory cells have a common theme - each takes several mechanisms and usually a few buildings to implement. A reasonably convenient and quick cell can't be had for less than ten mechanisms. Considering each mechanism takes one rock and a fair bit of time to make and installing/linking takes a fair amount of time and attention, it should be easy to see that memory is a serious limitation for dwarven computers. Even a modest kilobyte can easily take 100.000 mechanisms (more than the biggest machine on record that ever got finished), and you can't really do much computing with that little memory. 

With my concept of storing information purely in minecart weights and evaluating sets of carts selectively i managed to circumvent the problem to a degree: with eight different weight groups of carts, each cart can hold three bits of information, and reading can be grouped - you only read one set of carts at a time, while several other sets are kept in readiness. Consequently, i managed to build a memory array holding 768 bits of information at a cost of under 500 mechanisms. The downside is that this kind of memory would be extremely laborious and slow to write to, i never considered using it as anything other than a ROM. At three bits per cart, it also took over 200 minecarts to fill. A full kilobyte implemented like this may cost "only" 2000-3000 mechanisms, but it would also require about 2500 minecarts, each individually selected, placed and put in motion.

===Appendix: Destructive Reading===

If our memory cell has a constantly-active output, we're in trouble when we want to reference only one of several cells for use by another device. Transmitting the "state" of one of several cells to a receiver can be done by AND gates, e.g. mechanically:

{{Diagram|spaces=yes|\
.
Power in
  ║
┤┤┤┤┤┤ "distributor" roller
☼☼☼☼☼☼ state 1-6
☼☼☼☼☼☼ select 1-6
┤┤┤┤┤┤ "collector" roller
  ║
Power out
}}

Each "state" gear assembly is linked to the output of a memory cell.
Each "select" gear assembly is linked to a "read selector". 
Power will come out (and activate whatever we've placed to the south) when both the state and the select gear of (at least) one cell are active at the same time. Having the gears next to each other doesn't pose a problem, since power only passes gears in cardinal directions; power can only get to a select gear - and through it to the collection roller and output - if the state gear of the very same cell is engaged. 

Clearly, this method works, but it requires a fair number of mechanisms installed and dissipates quite a bit of power. 

But we can reduce the architecture cost by reading the cells destructively. "Destructive read" means that we ''change the state of the memory cell'' and observe whether the output changes or stays the same. If the output changes, the cell was previously in the opposite state, if not, it was already in the "written" state. I've come up with two basic premises:

A - output to door or hatch, relevant is the last signal received, requiring flipping.

Under this premise, we link ''all'' the outputs we wish to collect to a single piece of furniture, preferably a door or hatch cover. In DF switching, furniture always takes on the state of the ''last valid signal'' it received. So if a door is linked to ten different memory cells, it doesn't matter if one or nine of the cells are in "on" state, it only matters if the last change in memory cells was from "off" to "on" or vice versa. To read a memory cell in this way, we
* first send a signal cycle to the door ("on" signal, followed normally by "off"), shutting it.
* send a "write" signal to the memory cell we wish to test, setting it to a specific value, either "on" or "off". The cell must have an output plate that goes active in the position we're setting the cell to in the read operation. I.e. if we read by turning the cell off, we must have an output plate that's active when the cell's off.
-> If the cell changes state, the door opens. If the cell stays in the same state, the door remains shut.
* now we test the shut/open state of the door with a logic device, e.g. by running a minecart so that it tries to pass, activating/deactivating the actual output.

The cost of this reading array consists of the door, its linkages, the testing mechanism for the door itself and a simple circuit to flip the door shut. We need no extra machinery for the destructive read itself - that's done by the same mechanism that's used for normally setting the cell to zero.

B - output to gear assembly, test via edge detector.

Gearboxes toggle their state whenever they receive a signal, no matter which kind. Thus, a gear assembly operates as a parity gate. Here, it doesn't matter what kind of signal was last received, it only matters if the ''total'' number of signals received since the gear was constructed is even or odd. We can simply link all our outputs to a single gear assembly, but of course, whether this assembly is deactivated or activated depends on how many memory cells in total are on or off. When we want to read a cell, we still just set it to a given state, but  now we only know that the gear assembly's state ''will change if the memory cell's state changes''. We cannot know whether it'll engage or disengage. Thus, we need something that only gives output upon state changes (a.k.a. an edge detector). Fortunately, that's pretty simple with minecart-actuated mechanical logic:

{{Diagram|spaces=yes|\
.        
#     #  
┬┴    ▲     
^┴☼   ║  
┬┴    ║  
#     #  
.
}}

To the left, the buildings. There are two rollers, both pushing to the north; one on the southern end, one on the northern end of the track. The northern tile is a track ramp with NS track. Power goes through the switched gear, distributed by a three-tile NS roller (push direction irrelevant, only used to provide power and hold up the roller on the ramp). 

When power is provided, a minecart on the track will remain on the ramp, held at its "top" by the roller. When power turns off, the cart rolls off the ramp, across the central tile and comes to rest on top of the southern roller, against the wall. When power turns on again, the cart crosses the central tile once more and gets dragged "up" the ramp by the northern roller. 

The result is indeed that this device produces no output in a stable "on" or "off" state, but does produce one signal cycle (on followed ~100 steps later by an off) everytime power supply changes. And since power supply changes everytime the gear assembly toggles, that produces our output. Evidently, this thing not only produces a signal cycle during reading, but when writing as well. We need further machinery to make sure the output is only processed when we actually want to read something. Still, the main cost of this reading mechanism is again the single gear assembly and its links. We don't need to "flip" our gear like a door before reading, making the reading process much faster. Once again, the reading itself is done by the normal mechanism that writes the reference state to the memory cell. 


Two final notes:

Destructive reads, as the name implies, destroy the memory state they read. We can restore the cell's state from the output generated, if we so desire, but that means extra effort.

Destructive reading allows relatively cheaper largish memory, but it still only reduces the cost per-bit from about a dozen to at best six mechanisms.