Update

mechanical.md

@@ -91,7 +91,14 @@ Using marbles (and possibly also similar rolling shapes, e.g. cylinders, disks,
 
 **Basic principle** is that of a marble performing computation by going through a maze -- while a single marble can be used to evaluate some simple [logic circuit](logic_circuit.md), usually (see e.g. [Turing Tumble](turing_tumble.md)) the design uses many marbles and performs sequential computation, i.e. there is typically a **bucket** of marbles placed on a high place from which we release one marble which (normally by relying on [gravity](gravity.md)) goes through the maze and performs one computation cycle (switches state, potentially flips a memory bit etc.) and then, at the bottom (end of its path), presses a switch to release the next marble from the top bucket. So the computation is autonomous, it consumes marbles from the top bucket and fills the bottom bucket (with few marbles available an operator may sometimes need to refill the top bucket from the bottom one). The maze is usually an angled board onto which we just place obstacles; multiple layers of boards with holes/tunnels connecting them may be employed to allow more complexity. { You can build it from lego probably. ~drummyfish }
 
-NOTE: Balls may be used to perform computation also in other ways than described here, very notable is e.g. the **[billiard ball computer](billiard_ball_computer.md)** (which also has a great advantage of performing reversible computation). However here we will focus on the traditional "marble maze" approach.
+NOTE: Balls, or potentially other "falling/moving objects", may be used to perform computation also in other ways than we'll describe further on -- some of the alternative approaches are for example:
+
+- The **[billiard ball computer](billiard_ball_computer.md)** (which also has a great advantage of performing reversible computation).
+- Another possible idea is that of the falling object ITSELF encoding a value (likely just a bit), for example imagine some kind of arrow shape which itself represents either 1/0 by pointing up/down, changing its orientation as it passes through the gates (we would also have to ensure the orientation can't change spontaneously on its own of course).
+- A bit can also be represented by presence/absence of the marble -- this is utilized e.g. by *binary marbles* (https://binarymarbles.weebly.com/how-it-works.html). For example the AND gate is implemented by one input marble falling into a hole, making a "bridge" for the other marble that then overcomes the hole and reaches output. Timing may play an important role as some gates (e.g. XOR) require dropping the input marbles simultaneously.
+- ...
+
+These approaches may be tried as well, however further on here we will focus on the traditional "marble maze" approach in which the marbles mostly serve as a kind movement force that flips bits represented by something else (or possibly indicate answer by falling out through a specific hole).
 
 The **disadvantage** here is that the computation is **slow** as to perform one cycle a marble has to travel some path (which may take many seconds, i.e. in the simple form you get a "CPU" with some fractional frequency, e.g. 1/5 Hz). This can potentially be improved a little, e.g. by [pipelining](pipeline.md) (releaseing the next marble as soon as possible, even before the current one finishes the whole path) and [parallelism](parallelism.md) (releasing multiple marbles, each one doing some part of work in parallel with others). **Advantages** on the other hand include mentioned simplicity of construction, visual clarity (we can often make the computer as a flat 2D board that can easily be observed, debugged etc.) and potentially good extensibility -- making the pipeline (maze) longer, e.g. to add more bits or functionality, is always possible without being limited e.g. by friction like with gears (though usually for the cost of speed).