ORIGAMI LOGIC, ? Yeah, sure, I'll try that!

[RJSV]

   Thanks to Discover Mag, the coverage on Origami being shrunk down in many applications, got me thinking, (mainly about existing work in digital logic gates).

   Picture shows a thing, intended just for illustration; a carelessly wound up plastic bag, and that sucker untwisted, taking up almost a full minute, moving in slow motion across the surface, as it unfolded.   Amazing is how easy the mechanical 'device' build potential is, ...almost 'pesky' !

[RJSV]

This second picture features the 'wound up' plastic just as released, to un-twist.

[RJSV]

   The first challenge would be to design an Origami equivalent (or close) to the typical RS Latch, like the '7474 flipflop.
   The paper folded would be about hand-sized, and store something in the variable folds...I'm looking at storing as an IN or OUT pointing triangle, or pyramid shaped projection, in the paper.
   Schematically, the switching structure could be a 'dimple' in a bigger dome-shaped base, either in, or pointing outward.  Then, (as picture diagram shows) a system 'BUS' line would be a series of those domes, each positioned to bump the next dome, when a 'pulse' comes through ...(whatever THAT is,...I'm a software guy).

   In such a Mechanical activated system, (shrunk down of course), might be advantage to have electronic storage on-board, for mass quantities of code segments for use.

[RJSV]

   Doing such a project, (and seeing the way such things often go, lol), it's tempting to try using a supervised random crumpling of paper.

   A mechanical R-S Flipflop would have placed to push, similar to a push button, where the little push will cause a folded area to change, usually a simpler bi-stable deal, but would be like a mechanical latching push-button.
Push on the 'S' or 'SET' area, and the origami unit assumes the 'SET' type of shape possible.
But it's the reading and subsequent BUS activity that is challenging, to think up!
   You need a simple 'Reader' or synchronizer pulse input, that, (somehow), gets transfered out as data just read, by being different, according to the data being read;  That means that, for example, a 'dimple' raising output could come on either an outlet labeled as 'zero' or another as '1', according to system word size.

   Note that the method is representing a binary number, but actually uses just symbols, not caring about a binary 'state'.   That's actually literally 'Base One', an argument best left neglected for now ...

   But the little Origami test device would resemble an older switch box, say for a drill press or other heavier shop machine, having a Start button, etc.

[RJSV]

   The way I see this working, is of course more than just flipflop storage.   With a 'Dry BUS'  the data is asserted by a brief, pulse-like or transient pushing force.
   By way of an interrogation pulse, (I like to call 'Read-Sync), all the business of 'CE' or 'Chip Enable' is avoided, as the controller issues a simple 'RS' to read contents.  This way, besides handling BUS contentions, the (origami) device can actively transmit or send a typical 'zero' as that being a symbol, for purposes of data transfer.
   An example could be using 16 of the origami gates (or latches), as implementation of a
 four-bit system (BUS)...  That is; it's made up of 16 'gates' that as a set will have only one gate active, thus it implements an equivalent of 4-bit binary, while 16 physical channels are observed.

   Looking at the twisted, folded cardboard thingy, you can imagine how the output, for each of the particular states, would be the rise up of the pyramid or triangle shape, thus pushing on that, distinct BUS line, going next to the device doing the reading.

   That next device would have been set-up already, by way of path setting or, really, addressing.   The incoming 'push' or mechanical pulse would determine which device state gets set.   First would be the simple 0 and 1 set, as a single binary-like function set.

[ebastler]

If I understand you right, the fundamental flip-flop you have in mind is a bistable structure made of paper. There is published work in that direction, although the main thrust seems to be structural components and building techniques. (E.g inflatable structures which then stay stable in the expanded configuration, without needing sustained air pressure to support them.) If you want to search for them, including the "bistable" search term is probably going to be helpful.

But I see big challenges in building read-out and control mechanisms from paper too. Especially without glue, using folding only, in proper Origami fashion.

Since you have shown interest in different mechanical binary computer designs in the past -- have you ever looked into Konrad Zuse's Z1? A fully mechanical binary computer, made from sheet metal logic gates and driven by an electric motor, built from 1936 to 1938 in his parents' living room. The gate design is well-documented, although not easy to understand. 

[SiliconWizard]

What about quantum Origami?

[AVGresponding]

What about quantum Origami?

We already have that, it's called "protein folding".

[RJSV]

   Yes, ebastler, we've crossed paths on this before...many mechanical systems would have to rely on so-called 'Dry BUS' interfacing, where, as opposed to the standard TTL style of output, each device only manipulates the data BUS during a short little 'pulse', rather than over some timed or clocked interval.
   Results are similar, though, but it's just that there isn't any interface or chip-enable on each of the multiple connected devices, the READ command impulse serves to be re-used, as a properly formatted output, as a fully decoded signal (thats the BASE ONE argument....).

   I'm imagining using those saucer or dome shaped logic 'gates', where an outward dimple is considered the 'on or One' device state.  Plus, though, there needs to be a relaxation mechanism, returning a 'dimple' back to the relaxed state.  THAT could be a tough problem, as regards to device delay or throughput limits.
But my initial idea is to attach a second dome/dimple component, one that gets pushed into the path required, as the signal passing mechanism...while some other device or group of devices has such a dimple switch put into 'no-pass' mode.  That way you've gotten a means for reading one device's state, and putting it 'on the BUS'.
   You get a similar outcome, inside each single microprocessor action, as takes place now, with using the 'CE' logic to determine BUS access privalege.

   On this type of system, say with 16 states, when transferring a number, like a '7', that single pulse happening on the '7' line is uncoded, and simply is saying a command, to 'Set in a 7' to a device (being written with the data).

   Much of the LS 7474 RS Latch functionality is fairly easy to imagine,...in an origami, but it is the data transfer stuff that is critically needed for full use among the various BUS connected devices.  A general purpose way to do the data transfers necessary.

[RJSV]

CORRECTION:  Sorry, I had meant to say, recalling article on ORIGAMI was actually National Geographic...(not Discover).

   Viewing the enclosed photo, you can see I've used a US Government letter, as a trial folded randomly, as random Origami, as suggested might be just as good a method, vs. designed folds, where each randomly folded object is then tested (for the function you'd want).
That's part of the 'design' process that I found interesting.
   Now looking at specific function, from the TTL '7474 Latch you've also a clocked data input.
When testing for that you would need two fingers; one to be 'poking' in a device clock action, and a second finger to 'poke' in the data bit, in some fashion, as to whether it's conventional 0 or 1 type, to be pushing or not, or whether it's explicit; by way of 'poking' on either a zero input or a discrete, separate 'ones' input (on the paper origami surface).

   You would be pushing on the data input, that way, plus you would then 'push' on the clock, as trying to get as close as possible to emulating the LS7474 gate actions.

[RJSV]

   A preliminary layout schematic for a data carrying BUS line, or channel, is pictured, showing side views of each dome, each dome having a revert to base state, after a (hopefully) short time.
   Moving from left to right, on the illustration, the couple of currently active domes are in the cascade ... and soon that wave of cascading dime 'dimples' will be over to the gap shown.  At that point there may, or may not, be a dome used as temporary link, in the cascade chain, which could spell the end of that pulse cascade.
   Doing that (schematic above) on two separate outputs would give the proper function, doing a multi-position switch, (or one to several
selections).

[ebastler]

Hmm, so far I can't see how you plan to achieve logic functions (and control over them) with this approach.

The arrangement in you latest drawing seems to do somehting similar to a row of dominos: Push one brick, that will tip over the neighboring one, etc. -- in a cascade that can't be controlled further once it has been started. The timing seems to be defined by hard-to-control implementation details of the individual elements and their interaction (stiffness, hysteresis and distance of your "bubbles"), rather than by a central clock. And how would basic logic functions (AND, OR etc.) be achieved?

I might be missing something; or maybe what you have is just a nucleus and those missing aspects have yet to be developed?

[RJSV]

   Actually, I'm a kind of a Data Transfer snob, but seriously the ALU and regular logic stuff is, quite trivial, in comparison with the whole traffic control aspects.   It's largely done in symbol form, which avoids the 'voltage not there' or other aspects of Boolean.
   You might call this 'The Abandonment of Binary...', maybe a little dramatic, but it's more a supplement.   My imagined personal 'system' would have a modern electronic processor, mostly for the huge memory possible there.
That is, besides the customized Origami included.

   Starting at hand and eye convenient sizes, approx. fist sized, but then (would like) shrunk down a modest amount...say 80 microns component size (per origami gate).

[RJSV]

   Picture shows an equivalent of some origami 'dome', bi-stable dimple would perhaps be a different composition.

   All speculation / speculation

[RJSV]

   As to the various BUS and signal concepts;
I've done some coverage here on EEVBLOG before, in recent years and don't wish to simply repeat the material (boring ?).
   After careful consideration, I feel there is enough potential interest, and newer readers, for justifying improving a clean / detailed presentation.
   
   Dictionary 'BINARY' means having two parts, or things, for numerical notation that has '2' rather than '10' as a base.

   First thing is to distinguish things, where something like an electrical BUS can have two valid 'states'...but may or may not be a part of a larger scheme of encoding numbers, for transmission or for direct processing.
   A decimal based system, for example, could be (internally) using typical two-state or
  'ON-OFF' switches, but would still be considered as 'Decimal Based' in it's main interactions (with other electrical circuitry).  THAT, by analogy, would be like saying that us humans utilize speech in a myrid of language style forms, but create  that speech through common breath and 'utterance' actions....vowels consanances, etc.

   In the diagram you can see obviously two-state switches, but which are implementing something as a group (of four signals).  Reasons for getting so specific is that confusion can set in, between some device, having two valid states, and a larger context, where multiple signals are organized in some specific way, and aren't (necessarily or purely) binary numerically.
That also is the case when two valid defined states exist on a BUS voltage line or channel.
   
   Consider a hybrid, for example:
   Suppose you've built an 8-bit (8 signal) BUS, having 7 bits of binary coded number, plus having a Parity bit.  Now, virtually all of that is built of binary components, yet the ultimate result is not, purely, a binary coded 'word' (due to the presence of the special Parity bit).
Closest maybe would be to call that 8-bit system a 'variation on binary coded numerically'.

[RJSV]

   Reader ebastler, please hang-on a little bit, while I attempt to explain thoughts on the use of 'BASE ONE' in calculations or counting.
Jumping ahead of myself, slightly here, an advantage to be gained is that easy translations are do-able while staying within the definition.
That means using conventional looking right and left shifts can be utilized for making usual increments, or decrements, of your BUS system 'word'.
   For doing the simple translation you will need a defined style or format that has ONLY one single signal  within each word.   Contrast that with the defined 'UNARY' base one word (see Wiki), where the Unary format resembles a Tally;   To represent the number '3' for example, you would have '0000 0111' in a simple Tally style.  (That example having word range, from 0 up to '8' max.)

   For the BUS style I'm suggesting, you would turn on a SINGLE position, or BUS channel, vs that Tally style, just mentioned.  That way, a number like '0000 1000' (using 8 BUS lines or positions), is representing a 'three' and is only distantly similar, to the Unary representation.

   You could call that a 'one signal and only one' style, and that's the format that can be easily translated, by way of BUS line shifts or other manipulation.   Note that a ZERO value would look like '0000 0001'  which, as was explained, provides the same opportunity to use shifting.
To bump a zero (increment) by adding one to it
you simply need a segment of BUS that translates via conventional left shift.
   Other simple general purpose translations are also possible.   For example, you could pass all values unchanged except for any '3', which could be altered (translated) into another BUS value, such as changed into a '0' value.  Although that's an odd-ball function, it can be easily done.

   The better calculation results come when you start using 'LOOKUP TABLE' style ALU calculations....avoiding using logic manipulations altogether.

[ebastler]

Hi RJSV -- we may be using different nomenclature here. What you discuss as different "bus" designs, I would call different number representations.

A "bus", in my book, is a device which transfers data from one source (or one from a multitude of selectable sources) to one or more destinations. In the typical electronic computer, a group of wires, with multiplexers and drivers as needed. In a mechanical computer, a set of levers or similar devices.

Building a bus from Origami elements seems challenging to me. The cascade of bistable "bubbles" which you showed earlier can indeed transmit information (in a "falling dominos" way) -- but can it transmit both 0s and 1s in the same direction? Can it be coupled to multiple inputs and outputs?

Regarding number representations, I am not sure whether the unary system is the right one for a "paper computer". I can see how it is useful when you base a computer design on movable discrete objects, like marbles. But for a computer designed from stationary flip-flops, I don't see how a unary design helps:

Compared to a binary number representation, unary requires a much larger number of flip-flops to represent a given range of numerical values. And how would you implement addition, subtraction, comparison?  For a marble-based computer, you can merge or split sets of marbles, compare two sets on a balance etc. But for a computer based on stationary flip-flops, I don't see an efficient way of performing these operations in unary representation.

Edit: That other representation you suggested (setting one bit and one bit only) is also known in the literature; often called "one hot" encoding. It is used frequently to represent a discrete set of states, e.g. to control actions in a state machine: Having one active bit per state makes it easy to let these bits control other logic, depending on the current state. But again, I don't see an obvious way to do arithmetics with "one hot" encoding. It is difficult to beat binary representation there, where a one-bit full adder with carry is all you need as your basic functional element, and these can be cascaded as needed... 

[RJSV]

   ebastler, thanks for good questions!
   One motivation for using some alternate forms, from more familiar binary, could actually be that the differing needs call for it, (perhaps even being the 'ONLY' way forward...that's a convenient excuse.
   But, while offering up excuses, I have to point out;  some of the past projects have involved various forms useful for TEACHING...and that brought forward a whole spectrum of systems that are BIG, Noisy sometimes, and perhaps loaded with whimsical (and useless) structures, designed to catch the attention of the, um, errr, 'typical 7 year old' student.   In that context, a 9 foot tall (3 meters) 'system' has the appeal and attention holding power that teachers seek.

   Now as to some recent questions: with the 'dry bus' you don't have the multiple devices hanging on, but rather there is a tree-like decode, for ultimately sending to only one 'target' place.
   In the diagram included, the decoded are each done as '1 of 4' to simplify, where the binary range equivalent is '2 bits'.   This scheme also include a signal to READ, along with, in this example case, the '4' states that can be written.
So, in my diagram, each of FIVE total lines exist in that read and write BUS.
   One consolation is that the address numbers are already in 'decode' form, and thus can be used straightforward, for that 'tree' decode process.  I found that simple decoding or setting up the path switches can be done serially, once per each address word, thus completing the path through the 'tree' to ultimate target location.

[RJSV]

   Now you DID, however, miss the biggest feature, of the 'One hot' stuff, which is the ability to avoid the (awkward) mechanisms for transmission of the 'zero' state, which is neither a positive signal, nor any other sense of 'action'.
(Sorry, I know it's an awkward explanation).
The 'zero' case, especially with voltages, is usually supplied by a default mechanism,...problematic for mechanical devices, especially with non-clocked or asynchronous.
   With this symbolic oriented system, any 'zeroes' aren't treated as such, any different than any other value, in the range of your 'word'.
A 'zero' is simply another pulse, although it does get treated properly for doing math.
Plus, that keeps some kind of pulse there, for when you want to translate, like 0 to a '4', or when you want to increment, by moving the 'zero' symbol pulse over by one BUS column.
(You cannot move a binary style 'zero', in other words.)

[ebastler]

   Now you DID, however, miss the biggest feature, of the 'One hot' stuff, which is the ability to avoid the (awkward) mechanisms for transmission of the 'zero' state, which is neither a positive signal, nor any other sense of 'action'.

I don't think I get that point. Let's say you have some valid value in an 8-bit "one hot" register -- i.e. one of the bits is set to '1', the others are '0'. Now you want to transmit that value to another register, which previously contained some other value.

Don't you have to transmit the '1' and the '0's as well? You need to overwrite the prior entry in the destination register, i.e. one of its bit was '1' before and needs to be changed to '0'. And you have to transmit 8 bits instead of the 3 which would be sufficient in a base-2 representation of the number, so you need more data lines.

Of course you could say "I clear the destination register first, and then I just transmit the '1' bit." But that would be possible in a base-2 representation as well, wouldn't it?

[RandallMcRee]

Is this relevant?

https://www.quantamagazine.org/how-to-build-an-origami-computer-20240130/

[RJSV]

   You still are missing the point....there isn't any mathematical meaning, to just sit there, transmitting, (or uttering) 'nothing'...in absense of having a qualifying clock, or flag.
   For example, suppose I'm just sitting in a chair, in front of you, totally silent.  That doesn't have any time quality, so not very useful.  Now, suppose we agreed, that you will write down what sounds there are, if any, when my flag is raised, then dropped.  That gives valid data.
   Suppose then, that we change the rule, so that you sit, waiting, and then act, to write down any active utterance, simply when it comes.  Doing things that way will allow communication even if the data sent is 0, or, literally due to the fact that your 'symbol' is an active thing, not just 'silence'.
   At any rate, in the context here, it simply implies that you can have one of your 'tokens' or symbolic characters in place of....(in place of what?).   I wrote it that way, because us humans even USE A SYMBOL, when denoting zero..or nothing...it's that little round circle ; ' 0 ' (sorry to be a little snarky).
=====================================

   As to the component counts, yes they do go up quite rapidly.  But that effect has its limits, enlarging each individual word (parts count), but not affecting in the larger scale.  That is, with a memory requirement of approx. equiv. to 100 bytes, you might have more components per word, but still have about 100 total words.

   Within the word for 16 states, you could see about 4 times more raw bulk, vs the 4 bits needed, in implementing straight conventional binary.   Like I said,  we may have to be dragged there, kicking and screaming ...
   It DOES help eliminate the need for decoding the 'efficient' binary coded bits...every time, lol.

[ebastler]

Hmm... what is the difference in "symbol quality" between a one-hot set of many zeros and a one, vs. a base-2 set of some zeros and some ones? How would the two systems differ in their need of a clock (or lack thereof) when transmitting information?

This is either too philoshophical for me, or a bit half-baked on your end; I'm not sure which.   Maybe if you could share a more complete proof-of-concept design, that would help to clarify.

What would be an interesting but feasible task? An adder maybe, which can add two numbers in the range of 0..3? Throw in subtraction or sign bits for each number for an extra challenge... 

[RJSV]

   Maybe half-baked, I dunno.  Certainly half-explained, but it's a complex system, so...uh...
Some culture historians could or might describe Computer Sciences as up there, in the complexity list, of mankind's inventive scope.   Maybe nuclear science stuff is more intense.
So, here, the list of unexplained grows frustratingly long.
   "You haven't explained how instructions are fetched...".
   "...A simple adder, and you haven't even described the half-carry...."
Etc. etc.
   I'm talking mostly about an approach that puts priority on data movement, and formats that make it easier, or even POSSIBLE.
If you can get the useable data access, to a simple table, and also if it's fairly easy to move your ALU inputs into address space, then that gives your ALU functions, in rapid look-up form.

   Example 2 digit decimal multiply, '9 X 9' would need two tables, each of 100 positions (ten by ten).   The upper digit determines blocks of ten answers, while lower variable input (X), determines position of an answer digit.  You will need a ROM block for the '1' and another for the high digit answer, '8'.
   Of course, this whole thing is potentially quite bulky, and overkill when doing simple addition, but on the other hand does replace a bunch of 'random' logic.


BTW, example of a serial interface, such as RS232, notice that each character uses a 'Start bit', as an explicit and noticable flag, to the receiver as a 'heads up' alert.  That's because your receiving device sees that as an active assertion, vs and idle line.

   We could go round and round, arguing....somewhat like arguing over a primitive, where there isn't much substance showing...like arguing over the meaning of 'THE'.
   But hold on, and keep asking,...it's worth while

   I did get some extra ideas, suppose you add an extra column, to the 'One Hot' definition;
   '0000 0000' would be invalid / inactive.
   '0000 0001' would be a '0', numerically
   '0000 0010' = 1
   '0000 0100' = 2 etc
That would help get away from the whole 'zero is nothing' conundrum.

   Ditto for the 'Tally sheet' format, (where each representation is original number +1.)

[RJSV]

   Going a more traditional route, to describe operation of an ADDER, I would first consider using a loop, although a clumsy and slow solution. 
   Taking something like X + Y; you would first test the Y value, ending if it's zero.
For inside the loop, increment X and decrement Y, then test Y for done.   All very straightforward (but slow).

   Some of the most AWKWARD code, I bet, in an origami computer, would be the code that toils to perform some legacy binary based function (you guessed it).

[RJSV]

   Let's dip into 'Confusion Land' for a minute, might help:
   A person could stare at (latest diagram) and declare "look at all those zeros, in a binary hexadecimal number like 0b h,... or 1011b,  How am I to translate those embedded zeros, for this other format, then ?"
   That's a confused question in itself, but key to it is to view the number as a whole.  Any zeros are part of a conventional binary coded representation.   Out of the whole, 16 state word range, there is only one actual 'zero' value.

   Looking at a single binary bit transfer, (see diagram), that can send two separate states; a zero, or a one.   Now in this case we are only considering a tiny sized 'word', of two variations.   You put (a voltage) on one of the transmit lines, and then pulse a clock, in a second BUS line.
   On the bottom portion of this diagram is shown the alternate, which is to separately send one or the other, as a self-contained pulse.  Note that in that example you've used the same number of lines, for the possible state transfers.
(Next size up, 3 states or 4, would involve 3 lines in conventional binary code, while the larger set-up in the discrete signal type method will need FOUR lines, to be able to transfer 4 states.
   So, you don't actually 'translate' each instance of zero, but rather it's only the first state, in your word.   For a 16 state equivalent (conventional 4 bit, in binary code) you would need 16 discrete sending lines.

[RJSV]

...and BTW;   It might turn out to be most efficient, lower parts count, to use a 4-state BUS definition, equivalent to a (measly) 2-bits in conventional notation, per system word.   That way keeping the individual parts count down, while then having (4 times more) actual words...to end up with some desired memory capacity, like a modest 100 bytes equivalent, available to the little processor.

[ebastler]

   I did get some extra ideas, suppose you add an extra column, to the 'One Hot' definition;
   '0000 0000' would be invalid / inactive.
   '0000 0001' would be a '0', numerically
   '0000 0010' = 1
   '0000 0100' = 2 etc
That would help get away from the whole 'zero is nothing' conundrum.

Yes, that is the representation I was thinking of all along.

Did you previously assume that zero would be encoded as '0000'? I don't think that is a good idea, since it makes zero a special case, and one which is difficult to deal with. For example, suppose you want to count down a give number, e.g. to control your simple adder. You will need a mechanism which implements a loop : "If there is a '1' in the rightmost position, we are done. If it is a zero, remove that digit (by right-shifiting) and continue at the beginning." But what if the '1' never comes, because you started with '0000'?

I realize now that we were apparently talking at cross-purposes in the whole "can't (or don't have to) transmit zero" discussion. I was assuming throughout that we are talking on the bit level, i.e. the individual '0' vs. '1' state of a bistable element. While you were probably referring to the symbol level, i.e. zero = '0000'?

But I'm afraid I still do not get the problem (or the advantage?). To transmit any symbol like '0100', one needs to effectively transmit the '0' bits too: The '1' bit does not carry information on its own, but only due to the way it is embedded (positioned) in the '0's. And if one can transmit both, '0' and '1' bits, then one can also transmit the 'zero' symbol -- whether it is encoded as '0001' or '0000'.

[ebastler]

   Looking at a single binary bit transfer, (see diagram), that can send two separate states; a zero, or a one.   Now in this case we are only considering a tiny sized 'word', of two variations.   You put (a voltage) on one of the transmit lines, and then pulse a clock, in a second BUS line.

   On the bottom portion of this diagram is shown the alternate, which is to separately send one or the other, as a self-contained pulse.  Note that in that example you've used the same number of lines, for the possible state transfers.
(Next size up, 3 states or 4, would involve 3 lines in conventional binary code, while the larger set-up in the discrete signal type method will need FOUR lines, to be able to transfer 4 states.

The "clock + data line" approach becomes more efficient for a large number of parallel data lines. To transmit n bits in parallel, you need n+1 wires, while the "set and reset" approach needs 2n wires.

But the "set and reset" has certainly been used in practical computers. I studied the Pilot ACE (Automatic Computing Engine, designed by Alan Turing in 1945) a couple of years ago, and that's exactly how it works internally. And to my knowledge other contemporary computers typically took the same approach.

[RJSV]

   Yes but remember, I'm trying to accommodate a set of mechanical functions that often does not have the full, spread-out reach of some electrical 'voltage', or light beam, where many many individual components can receive and send on a BUS, especially with a synchronous clicking.   So, the extra hassle might be unavoidable.

   Plus, I'm reading the exact approach (that I just warned about):
   "We still have to transmit THOSE ZERO BITS somehow.".  Not really.   It's a whole state word, and not binary.   Only task is to send a zero when the WHOLE WORD is zero, and that action is the same, as sending a 'three' or a 'seven', etc.
It's just another term, sent symbolically, or actually maybe better to say 'encoded by way of channel, or line position'.

[RJSV]

   With a lot of needed discussion, the BUS issues takes attention off of the specifics here, where origami 'bubble' dimples determine device state(s), that may or may not be cross-applied as to (mechanical) marble ball movement techniques for data transfers.
   With focus back on the specifics of the BUS, moving 'dominoes' effects, we can see there might be needed an integral mechanism for putting each 'dome' dimple back to the starting 'resting' state, after transmission has passed by.
   One possibility would be to loop a portion of (pulse) signal back around, to reset each dome, in turn (but without looking like '0' data value).
That would be necessary, to explicitly clear each, rather than having some timing related fall-back.

[RJSV]

   Here is more info, to further clarify the issue of possibly inefficient or outright impractical component counts:
   Viewing the enclosed diagram, you can see an 11 element BUS in a (decimal) addressing scheme (for now).   The whole mess can be considered similar to a multi-position rotary switch, but also with extraordinary width (11 signals).
   Now the most convenient first stab at this gets you to something like 11p10t, or eleven poles, ten throws, similar to a classic (large) electric rotary.

   The somewhat bewildering aspects can be mitigated, in application.   For example, suppose you only need six locations to point to (6 BUS words)...; that would mean the diagram wouldn't be fully populated with the unused switch paths.   So in THAT comparison with classic binary switch trees the component counts will scale about the same.
What I mean to say is that the discrete signal BUS doesn't always 'blow up' the component counts, even though lacking in 'binary' efficiency.

   In this scenario, you would lose the parts count efficiency at the lowest level, but in organizing those multiple subassembly BUSes, the total counts are similar (the total number of sub-assemblies).
   All of this explanation helps to imply that things won't 'blow up' as an exponential, (although a 6X increase in smallest parts is plenty bad, for the designers.)

[RJSV]

   Close up view of the multi-port BUS switch helps to show details.
   The BUS width shown is 11 signals due to the 'Read Request' signal being included, along with 10 'Data Write' signals, (nothing encoded).

   Each segment is mass-serially connected, so that it's either 'Use for output's or 'Send to next switch segment'. 
   While much of this applies to a different style mechanical BUS, it gives a good start for examining the changes needed for the ORIGAMI version.  (Thanks to ebastler for suggesting the term 'domino BUS'.)

[RJSV]

   It can quickly become apparent that the tasks are calling for a designer having packaging experience and good spatial perception skills (vs outright Computer Science).
   
   In the enclosed diagram is shown a good, dense package style, where the individual horizontal rows are each a self-contained BUS, and vertical separations (columns) are for the individual signals within each BUS.
   So, in the ORIGAMI case, it would benefit to be able to design and build things in a flat 'PLATE' form, for simple stacking of the plates.
That would accommodate the mass of signals in an 11 by 10 BUS Switch output array.

   For the (old) 'marble' activated BUS style you might note that this is all largely PASSIVE structure, although tedious in detailed form.

[ebastler]

Finding the best overall architecture and spatial arrangement of gates will probably depend on the shape of the individual gates and flip-flops. Making bi-stable elements by folding paper does not seem easy; and I have no idea how AND, OR, NOT, XOR gates could be implemented.

(Well, maybe OR is the easiest among the three: Put two elements side by side; if one or both of them are in the expanded state, it/they will push the adjacent element. NOT could be a lever with two arms -- but how to make that from paper by folding only? There were some flip-floppy elements in the architectural Origami building blocks I had shared early on, but those all seem to rely on air pressure to unfold them, and I am not sure there is a controlled way to fold them back again.)

Have you thought about these gate designs already? It's probably good to look at this from both sides -- top-down architecture and bottom-up gate design -- alternately, because there will be a close interplay.

[RJSV]

   Thanks...(it's a big mess at this point):
   Might be a mistake for me to focus a lot, on the 'marble rolling' or 'particle token' structures from the past.  But not that much time involved.  Much of that approach is over 20 years ago, now!

   As to the packaging I would prefer to alter various outcomes with the goal of being in 'flat plate' form...if possible, for improved density, of something like an assembly of ten number latches for example.
   Some ALU functions like AND can be done, partially by way of 'OR', when using negated logic, that is when both inputs are 0 you get result of 0, otherwise a 1.

   In my mind, it's important to have all of the test and branch functions, that classic electronics employ.

   The origami approach is attractive because others are creating things currently there.

[RJSV]

   Attempts to the increase the packing density matter a lot, even if it appears to be frivolous, maybe.
   So while any one particular signal latch might be a convoluted mess (and look like a mess, lol), it helps consolidate things to organize as closely as possible to a 'thick plate' configuration.   That's because several plates will be stacked, in a hopefully efficient use of space...in 3D.
   Picture shows 3 of those latches, in first view, up top there, the 'random lumpy' latch assemblies are shown each with a output for an output BUS, but notice not much for dense packing.
   At picture bottom, I've shown the 3 mechanical origami latches packed in a way that has a dense region with all 3 outputs near each other.
This is facilitated by making sure that those 'lumpy' assemblies have the outputs up near an edge.

[RJSV]

   Second picture here shows that whole packaging game extended in another axis, with ideal output matrix in the same (X,y) matrix shown (a few posts back).  It uses a similar placement, up near an edge, but in upper corner the BUS runs can be missing interference with the other latches, by offsetting the assemblies somewhat.   (That was also the process with the first example offsets).
   In 3D thinking it is actually 'fun' and challenging to puzzle out things like this....not terribly impossible, but hard enough to deter some from going through the solutions.
You can have horribly convoluted :latch' layouts as long as there are ways to consolidate sets of such assemblies, into something as close to a big 'cube' as possible.

   Note that in this incomplete case, there is still a need to layout the input runs....they would collide with other latches without some accomodation.   That turns out to be fairly straightforward by way of being the inputs in at a slant, although that will make the 'PLATE' configuration a bit thicker.

[RJSV]

   There has been exploration, before, of the push-rod style logic, I just wanted to mention that it provides a definitive action, for both of the bi-stable states.   In the picture, are some rods, in a serial string.
Right away though, questions arise, as those rod strings can't 'push' or 'pull' indefinitely.  Some sort of force communication would also be limited, at least to a short time.

   A rod push and pull system could implement a 1-bit latch by using two inputs;
First input channel for data state.
Second channel is CLOCK input, that going from 0 to 1 and back to 0.

[RJSV]

   When considering what various options might look like, in diagram shown here is a data pulse transmission 'channel' or line, consists of many segments.
   Those individual segments are meant to show, schematically, some open-ended device, perhaps of origami.  Shown are little 'domes', serially arranged, that can have a 'dimple' or crumpled form,...and that is what gets propagated down and LOOPED-BACK to form an intended 'reset' wave that re-arranges each individual dome, back to so-called resting state.

   The two views shown are the sending wave (left side view), and, on the rt. side shown is the back-propagated 'wave' of resets.

[ebastler]

Yes, that's about what I was envisioning. Actually making something like that from paper -- and folded paper only, if it shall be true Origami -- seems like a challenge neverthless:

You would need elements which transfer an impulse (or their potential energy, if you want to look at it from that perspective) to their neighbor with essentially no loss, otherwise they will not be able to "flip" the neighbor's state. If unidirectional data transmission were enough, you could design it in a way where the elements get successively smaller or weaker to work around this; but if you want bidirectional transmission, that won't work.

By the way -- every desk should hold a few screws and a coffee mug!   Mine has the coffee mug, but I have just stored the screws away and only the screwdriver is still at hand...

[RJSV]

   (Screws in workbench photo are for fence.....I actually matched the older, crappy paint color !)

   Photo here shows an amusing DOMINO auto-reset, but needing a second channel.   Might be usable to perform in-transit logical inverts (logical 'NOT').

[ebastler]

That reminds me of something... 

[RJSV]

Haha out loud!   I've been thinking, comically, about the 'Self-Righting' Domino and some parallels with NASA SpaceX videos that feature 'Self-Rightious' rocket boosters.   You know,...the boosters control the upright position, and engine shut off, all exquisitely timed, and with those paddle airflow controllers (I assume airflow ?).

   A fatal flaw in the speculation on a signal transmission structure, from place to place, is that the reset pulse going backwards does ITSELF need to be reset, for next use.   That's an old familiar paradox, in this case needing infinite erasing and re-erasing and so on....

   Diagram shows, the signal reversing loop, with a splitter. The blue line denotes a signal meant to backwards-reset the original loop-back but note that process still leaves (the blue path) to be next erased....
   Not to mention the lossy line and attenuation from splitting the signal.   But at least a start at what may be required, eventually, as best option .

[RJSV]

Diagram shows, the outgoing data pulse can be reversed, to 'un-dimple' or reset the position of each dome.
   Might be possible to access each element, by way of loop-back that does an extra little turn, there, around the turn-around loop.

[Bud]

  

[RJSV]

   The sizing might be a bit strange, at 20 microns per segment.   That total is approx 400 microns, or just visible at about 1/2 mm.
   Initially figuring emulating OCTAL numbers by way of 8-wide or 8 channel BUS.   So that means you would need 8 of the pictured signal lines.  That would get total width estimate up to 1.2 mm. in very rough terms.

[ebastler]

Got to admit that I can't follow the "signal reversing loop" concept. Maybe it would be a good time to dive into the actual gate/flip-flop design for a while, for a reality check and to make things more tangible?

As mentioned a couple of posts earlier, I see a fundamental problem that you need ideal energy conservation or impulse transmission if you want to make those signal cascades work. That was an advantage of your earlier "marble computer" ideas: You always had gravity to help out and drive things. 

[RJSV]

Oh yeah...that pesky energy thing, lol.
   OUR devices don't run on it, (by policy).

   If I shift, to the register, flipflop etc. design then I'd likely stick to the (pulsed and un-coded) style.   For example, to set in a value like '#7' you would be sending on an identified 'column' that sits in a set, of {0,1,2,3,4,5,6,7} and, for now, is capable of actions on 8 individual rows, that being usually a 'reset'.   That way, all the other switches get cleared.   In this example, the '#7' signal also then puts the row 7 device into a SET position.
If not for pesky energy issues...

   Loop-back is, in schematic form, the reversed direction 'back-transmission' that, hypothetically, will reset or re-position 'dominoes' to upright.   For hobby purposes, I've surmised best scale is around 20 microns.
When estimating speeds, at about 1 meters per second, then comes out as about 1 millisecond to sweep through 20 gates, (or hypothetical domes).   Up and back would occupy about 2 milliseconds....that's before any subsequent use of the transmission channel can be.

[RJSV]

   Sorry if I appear maybe too 'flipant' in face of various intractable problems.   By experience, I've known 'intractable' to be, at least; negotiable.   When folks ask / comment on some (classroom  teaching) machine being too bulky or impractible;
I've often replied:
   "Size is for show...to get the student's attention;   and the SLOW speed is so it runs at the 'Speed of Learning'.

   Partially snark, but I've come across one fellow who lectured me on MODULATION saying you cannot modulate a fixed frequency'Beeper' circuit via software enable pin (or bit control of the beeper IC output).
Well that discussion went on for some time, meanwhile my little software patch wasn't working...due to an addressing difference, between machines.
   I had been 'modulating' various terminal's beeper to some success: obtained a buzzy but legible audio, even at lower musical note frequencies.
   I'll never forget the dry toned delivery, of that engineer coworker friend of mine, saying;
   "That'll never work !".
   "

[RJSV]

   Photo shows a particular sample of the potential looks obtained in the various manifestations of packaging.   In my case, I'm seeking, besides raw function, a case or package that has attractive visual qualities, to be used in various school teaching scenarios.

   Obviously just a couple of empty cookie trays at this point; but illustrative of subassemblies that might consist of origami logic or memory arrays.  Here, the clear plastic has 80 separated 'channels' that could contain the levers, etc. used in a multiple word memory array.
   The sample here has the two arrays, at 80 channels by 14, each.  Of course the intent is, also, to have some tiny scales of construction, but many prototypes will be larger, during development.

   This kind of 'Computer on Stage' or theatrical approach is part of the whole teaching thing; where (a teacher) must, firstly, gain the attention and interest of the students, if any hope of them motivated.

I've watched, from sidelines, as a talented clown 'entertained' a crowd.   Every single person there, in the audience was engaged and eagerly watching the clown produce various 'tricks' (with sleight of hand).
   That's what you want.

[RJSV]

   Today I have a great example, a single bit storage, (or latch), made of folded paper.

   In picture, I show a 3-piece 'sheet', of some packaging material.
The thick sheet can be bended, along those creased folds, with ultimately 2 separate but symmetric shapes.
Meanwhile, as this picture shows, you could be holding the left side section, while pushing with the right hand.

[RJSV]

   As this next picture shows, the actual shape includes a box shape, as the middle piece; meanwhile each of the two outside pieces are doubled.
The effect is very nearly the same, as just described, until you attempt to 'hold' one of the pairs, as a set.   Thanks means pitching things in adjacent pairs...but that can slide, freely relative to each other
As a plus, this sliding between the pairs is, mechanically like a gear-box in that it amplifies the input arc, into the output linear activator.
   The whole thing will store 1 bit worth of state.

[RJSV]

    A bit of a closer photo shows the small over lap or displacement between the card paper material.   That will reverse to other card, for the bit 'set' state.

[RJSV]

   A bit of detail, on how the folding actions get a 5 X mechanical advantage.

   I'm considering a CCW (Counter clockwise) folding as when the center box structure folds, to the left from a top view overhead.

[RJSV]

   Next, is shown the positioning with everything brought to maximum travel, (or some climax).
Like I've said; the fold lines have been creased so things almost go 'pancake flat'.
It's full CCW, and you can see the 'pancake' effect; where the walls of the box are offset, by the amount of the small walls.

[RJSV]

For the alternate 'folding' state, (please see picture), that's a CW or clock-wise folded object.
   Mechanical advantage is from activating or pushing an arc about 6 inches, meanwhile the sliding output moves about 3/8 inch, correspondingly.
That's about 16 to 1.

[RJSV]

Imagine now yourself standing, and gently rubbing hands together.   It's the act of withdrawal, or pulling a hand inward, that's the power-move.   With the paper card model discussion, there is a pairing of two flaps, still allowing sliding.
When the card model INPUT is active, there is a section, or strip that is 'folded' over a point, but also that blunt 'point' moves, so the thing is put into tension, causing withdrawal from the play field.
   So, I'm not certain if the 'mechanical advantage' is due to the length of the short wall, (of interior box shape).