dvgrn wrote:Conway and Gosper had p30 technology in 1970, so the first logic and construction circuitry was p30. With the primitive parts available -- block, eater, pentadecathlon, Gosper gun, NOT, and and OR gates, glider stream thinners and duplicators, and side tracking guns -- it was theoretically possible to assemble a working replicator, but the resulting pattern would have been far too large to simulate at all, let alone to test in practice through a full replication cycle.
For mathematically-minded Life enthusiasts, it was good enough to complete a proof (or two proofs, Conway's and Gosper's) that Life could support self-replicating patterns. But engineering-minded types felt kind of cheated by this: a theoretical replicator that could never be seen in action was the next worst thing to no replicator at all. To produce a proof by example, a specific Life pattern that could actually self-replicate, quite a bit of new technology would have to be invented.
Logic circuitry was already fairly compact in the 1970s, but it was limited to storing binary information, encoding a 0 or a 1 as the absence or presence of a glider every 30 ticks or 46 ticks. And universal computer-constructors need to be able to build as well as calculate -- but the side-tracking-gun mechanism was hugely inefficient at producing salvos of arbitrarily distant gliders with specific timings and directions. Something better was needed.
The stable Herschel circuitry invented by David Buckingham and extended by Paul Callahan in 1996-98 was, in theory, a huge step forward. It completely removed the painful limitation The "Spartan" subset of Herschel conduits, made out of small well-separated still lifes, was easily versatile enough to build arbitrarily complex computer circuitry.
Progress was very slow on the universal construction front, though. It wasn't until 2004 that Paul Chapman built his prototype stable universal constructor, implementing the key idea of a programmable construction arm: different signals would prompt the U.C. to pull the construction arm's elbow closer, push it farther away, or shoot a glider of either color sideways from the elbow's current position. The choice of operations -- PUSH, PULL, the two FIRE recipes, or a SHUT DOWN signal -- was made by reading a static tape where 1, 2, 3, 4, or 5 "1"s (in the form of boats) were stored in unary, separated by "0"s (blocks). That's an average of three or four bits of static storage to encode two bits' worth of information -- very inefficient, but it was only intended as an initial prototype.
Unfortunately there wasn't much further development of the idea until 2009, when Adam P. Goucher created a very large and complex "universal computer-constructor", where the "constructor" part was Chapman's unaltered prototype construction arm. Data storage for this computer was in proper binary instead of unary, but the general idea remained unchanged: construction data had to be stored on a static tape, and read one bit at a time. The result was a single slow salvo, with no control over the timing of the individual gliders being sent, only their order.
The significance of that limitation is that there's really no reasonable way to use data stored on a classical static binary tape to create recipes that involve pairs of colliding gliders. You'd have to store delay information for each of the two gliders, or at least one relative delay number -- as well as the INCs and DECs that produce the lane numbers for each of two guns.
That's probably eight or ten bits on the tape at a minimum, even with binary encoding, and the stable circuitry required to decode a binary number and turn it into a specific relative delay between two gliders would have had to be absolutely enormous.
Things somewhat like that have actually been done, e.g., in the original p1 megacell. That circuitry only had to decode a binary value and run a slide gun for an appropriate length of time, like k * 2^N where k was the decoded value. That already required a huge sprawling mass of circuitry, and producing exactly timed gliders in increments of a single tick, say -256..255 or some such, would have been a much larger project than that.
So in 2009 it seemed pretty obvious that unidirectional slow salvos were the way to go, because they could be encoded on a static tape relatively efficiently, and could be read from the tape by a manageable amount of stable circuitry, as shown by Paul Chapman's prototype.
The sudden appearance of the Gemini has been described before, so maybe some existing text could be reworked -- for example,
in LifeNews, Adam described how it differed from the "Standard Architecture".
The Gemini instantly showed that the Standard Architecture was just plain silly. Obviously (with hindsight) if you want to build some kind of memory storage system for a bunch of spacings between gliders, you just store a bunch of moving gliders at the spacing you want -- no need to bother encoding anything at all!
That one insight allowed a complete oblique self-constructing spaceship to be created, even using extraordinarily sub-optimal components. The prototype universal constructor was a first proof of concept, not really intended to be used anywhere since it could easily be made so much smaller. But Andrew Wade wasn't any kind of stable-circuitry expert, so he just used what was available: the Gemini spaceship included not just one, but three complete copies of the prototype construction arm, almost completely unmodified. All he did was throw away the hopelessly inefficient static binary storage system and substitute something better. Gemini's storage mechanism was so efficient that it was _still_ possible to create a full self-construction recipe for all that circuitry.
Side note: immediately after Paul's prototype was posted in May 2004, I found I didn't like the static tape very much -- so I threw it away and substituted a memory loop full of recirculating gliders. Both Paul's pattern and mine are in Golly's Signal-Circuitry folder. You'd think storing data as a glider stream would be a step forward, since that's exactly what the Gemini did -- but unfortunately I totally missed the point. My memory loop just held a simulation of the output of Paul's static tape, which then ran through the same complex and inefficient interpretation circuitry. I completely failed to see the opportunity to code the required timings directly... so that had to wait for Andrew Wade to come along a half-decade later.