v50 Steam/Premium information for editors
- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
This notice may be cached—the current version can be found here.
Editing v0.34:Memory (computing)
Jump to navigation
Jump to search
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
You are editing a page for an older version of Dwarf Fortress ("Main" is the current version, not "v0.34"). Please make sure you intend to do this. If you are here by mistake, see the current page instead.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | + | Memory is used for storing values and states in dwarven [[computing]]. Typically, binary memory is used, but this isn't strictly necessary. There are multiple ways to set up a memory cell, depending on whether one is using [[mechanical logic|mechanical]], [[fluid logic|fluid]], or [[creature logic]]. With binary memory, each cell has two possible states, generally referred to as 0 and 1, or true and false. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===Performance=== | ===Performance=== | ||
+ | |||
Memory systems in dwarf fortress, thankfully, are very good at maintaining their value (in the absence of any [[troll]]s), but they are still plagued by problems with latency and long refractory periods. Latency refers to the length of time before which a change in value will register, and the refractory period refers to the period after writing to memory during which one cannot reliably write to it a second time. Because of the delays involved with [[pressure plate]]s, latency and refractory period for a given memory cell often depend on which state the memory is being changed to. For instance, the mechanical hybrid cell below has nearly no latency when being written as true, but around 100 ticks of latency when being written as false. | Memory systems in dwarf fortress, thankfully, are very good at maintaining their value (in the absence of any [[troll]]s), but they are still plagued by problems with latency and long refractory periods. Latency refers to the length of time before which a change in value will register, and the refractory period refers to the period after writing to memory during which one cannot reliably write to it a second time. Because of the delays involved with [[pressure plate]]s, latency and refractory period for a given memory cell often depend on which state the memory is being changed to. For instance, the mechanical hybrid cell below has nearly no latency when being written as true, but around 100 ticks of latency when being written as false. | ||
Line 40: | Line 9: | ||
==Fluid Logic== | ==Fluid Logic== | ||
− | + | The simplest fluid logic latch relies on an infinite source and infinite drain, storing information in the form of the presence or absence of water in a particular location. | |
{{diagram|spaces=yes| | {{diagram|spaces=yes| | ||
═════ | ═════ | ||
− | [#0F0]~[# | + | [#0F0]~[#FF0]X[#F0F]^[#FF0]╬[#0FF]~ |
═════}} | ═════}} | ||
− | In this design, water flows from an infinite source {{Raw Tile|~|#0F0|#000}} over an output [[pressure plate]] {{Raw Tile|^|#F0F|#000}} toward an infinite drain {{Raw Tile|~|#0FF|#000}}. Its flow is controlled by | + | In this design, water flows from an infinite source {{Raw Tile|~|#0F0|#000}} over an output [[pressure plate]] {{Raw Tile|^|#F0F|#000}} toward an infinite drain {{Raw Tile|~|#0FF|#000}}. Its flow is controlled by a [[floodgate]], {{Raw Tile|X|#FF0|#000}}, and a raising [[bridge]], {{Raw Tile|╬|#FF0|#000}}, both linked to the same input. When {{Raw Tile|X|#FF0|#000}} and {{Raw Tile|╬|#FF0|#000}} are open, water will cover {{Raw Tile|^|#F0F|#000}}; when they are closed, there will be no water. Thus, the input source toggles the state of the memory cell, and the state of the memory cell is reflected in the output of {{Raw Tile|^|#F0F|#000}}. |
− | + | This is an example of flip-flop memory. The state of the memory can be toggled, but it's not possible to write one particular state (that is, for instance, true) to the memory without first examining the memory. This can be altered by replacing the bridge and floodgate with independently triggered doors. This design has relatively high latency, because of the flow rate of water, and a refractory period of 100 ticks, representing the delay associated with bridges and floodgates. Given careful enough design and sufficient water pressure, the latency of a write to true can approach 100, with the latency of a write to false around 120. | |
− | |||
− | This design has relatively high latency, because of the 100 | ||
==Creature Logic== | ==Creature Logic== | ||
Line 87: | Line 54: | ||
This design has very good latency (from almost nothing for a write as true to 100 ticks for a write as false) and no real refractory period-- it can be written to immediately following a previous write, although it does depend on the completion of the previous write signal (receiving the off component of the signal) before writing again. | This design has very good latency (from almost nothing for a write as true to 100 ticks for a write as false) and no real refractory period-- it can be written to immediately following a previous write, although it does depend on the completion of the previous write signal (receiving the off component of the signal) before writing again. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Memory addressing== | ==Memory addressing== | ||
Line 126: | Line 61: | ||
==Alternate design== | ==Alternate design== | ||
− | Because most memory is used for a specific application, there is no single best design. It is not uncommon to see functionality built into memory circuits-- a simple circuit that increments contains its own memory. Alternate designs are important when memory needs to be written to in various ways (toggle versus specific value) or when latency and refractory period are unimportant compared to resource requirements such as space. | + | Because most memory is used for a specific application, there is no single best design. It is not uncommon to see functionality built into memory circuits-- a simple circuit that increments contains its own memory. Alternate designs are important when memory needs to be written to in various ways (toggle versus specific value), when it needs to receive different kinds of input (a steady on or off versus an on-off cycle), or when latency and refractory period are unimportant compared to resource requirements such as space. |
{{Category|Computing}} | {{Category|Computing}} |