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

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