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

[[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 addition and subtraction.

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

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

[[File:Kippschalter.png]]

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

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

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


===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. 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.
{{diagram|spaces=yes|\

   ╔╗      ╔╗      
   ▼╔╗    D¢╔╗     
  #▼║▼╗   E¢║¢R    
   ║╚▼║    A^▼║    
   ╚═╚╝    ╚═╚^B   
  Paths  Buildings 
}}


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.

{{diagram|spaces=yes|\
.                           
   #    #        #          
   ▲▼   ║╗       ▲¢A        
   ╚▼   ╚║      a^▼         
   ║║   ║║       ║^c        
   ▼╗   ║╗       ▼^b        
   ▼▲   ╚║      B¢▲         
    #    #        #         
Floor, Track   Hatches,     
Ramps       Pressure plates 
.                            
}}

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.
@@ Line 1: / Line 1: @@
-'''Advanced circuits'''
+'''Dedicated devices'''
@@ Line 28: / Line 28: @@
 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.
+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===
@@ Line 38: / Line 38: @@
 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.
+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===
@@ Line 50: / Line 50: @@
 [[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.
+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===
@@ Line 57: / Line 59: @@
 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===
@@ Line 74: / Line 74: @@
 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===
@@ Line 101: / Line 86: @@
    ▼   ║   ▼    ▼
    ▼   ║   ¢s   ¢s
-   ║   #   ║    ┼e
+   ║   #   ║    +e
    ▼   ║   ¢r   ¢r
    ▼   ║   ▼    ▼
@@ Line 111: / Line 96: @@
 }}
-Track/ramps
+. Track/ramps
-engraved track on the ramps in the pits
+. engraved track on the ramps in the pits
-buildings
+. buildings
-space-saving expansion using a door to "e"nable the cell, designed by Nil Eyeglazed/VasilN.
+. 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.
@@ Line 125: / Line 110: @@
 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.
+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.
-. Adding dedicated "read" branches
+. 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.
 {{diagram|spaces=yes|\
-.
-  #    #
-  ▲    ▲
-  ^    ║
-  ¢o-  ▼
-  ▼    ▼
-  ║    ║
-  ▼    ▼
-  ¢s   ▼
-  ┼e   ║
-  ¢r   ▼
-  ▼    ▼
-  ║    ║
-  ▼    ▼
-  ¢o+  ▼
-  ^    ║
-  ▲    ▲
-  #    #
+   ╔╗      ╔╗
+   ▼╔╗    D¢╔╗
+  #▼║▼╗   E¢║¢R
+   ║╚▼║    A^▼║
+   ╚═╚╝    ╚═╚^B
+  Paths  Buildings
 }}
-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.
+All ramps are engraved with NS track.
-. Short-pulse memory cells
+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.
-{{diagram|spaces=yes|\
+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.
-   #   #   #     #       #
-   #   ║   #     #       ║
-  a¢   ║  a¢    a¢       ║
-  c+   ║  b┼    b┼       ║
-  b¢   ║  c¢    c¢       ║
-  ╔▼  ╔║   ▼     ▼══╗    ║══╗
-  ║+d ║║   ║    d┼ ║╝    ║ ║╝
-  ║^  ║║   ▼     ^▲▲▲    ╚╔║╗
-  ▼╗  ║╗  d¢      ###     ###
- e¢▲# ╚║#  ^     III.a   III.b
-  ##  ##   ▼
-  I.a I.b  ☺
-          eG
-           #
-           #
-           II.
-}}
+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.
-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.
+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.
-Key for all cells:
+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.
-a - set
-b - reset
-c - enable
-d - request for an output
+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.
-e - building that moderates the delay for returning the cart
-I.: building-moderated delay, lateral bypass
+===Mini-Excursus: Material costs of different memory designs===
-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.
+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.
-II.: building-moderated, vertical bypass
+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.
-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.
+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...
-III.: path-moderated, lateral bypass
+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.
-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.
+End Excursus.
-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.
+== Size-optimised incrementer ==
-''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.
+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.
-Similar and better timing for reading stored information is possible with fluid-mechanical logic, at the price of power consumption.
+{{diagram|spaces=yes|\
+.
-. One-building toggle memory cell
+   #    #        #
+   ▲▼   ║╗       ▲¢A
-{{Diagram|spaces=yes|\
+   ╚▼   ╚║      a^▼
-.
+   ║║   ║║       ║^c
-     ###
+   ▼╗   ║╗       ▼^b
-    ╔▲▲▲
+   ▼▲   ╚║      B¢▲
-    ║ ║╗
+     #    #        #
-    ║ ╔╝
+Floor, Track   Hatches,
- ╔══┼▼▼^▲#
+Ramps       Pressure plates
-#▲  ▼
+.
-#▲═╔▼
-#▲╚╝#
-}}
-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).
+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.
-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:
+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.
-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.
+A "carry-out" pressure plate is included at position "c", which gets activated on every second counting event.
-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.
+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.