Draft wasn't published, whoops.

-----

Been all gung-ho on this circuit [sims]...

Relays everywhere, no more TTL/CMOS, no diodes.

Actually, in a lot of cases the complexity has *reduced*.

Am discovering that there's a lot to learn with relay-logic that is seldom considered for boolean logic... E.G., there are *three* states with an SPDT relay... NC-open/NO-closed, NO-open/NC-closed, and *both* NO and NC open (while switching). And, similarly, an SPST-relay can be "on" in its coil, but still (briefly) be "off" at the contacts.

This, then, leads one to consider the previous logic operation's output and the next stage's input a little differently than for TTL...

Combined-with: a string of logic may be *significantly* simplified by changing things like "active-high" vs. "active-low" in intermediate stages... even if, intuitively, it seems odd... 

But, even still, it's not a simple matter of "here's three ways to implement AND, choose one", since it's really less about the boolean-logic and more about the end-result.

E.G. The write-verification circuit is simple: XNOR the read-back-value with the write-value, if the two are the same, then XNOR is 1, and the write-process is complete. Simple!

This is as simple as throwing a SPDT relay coil across those two signals. If they're equal the relay will remain off. OK!

But, now I need a bunch of logic between that output and the End-Write relay (or before its inputs) because: It should only end-writing if it's writing AND we're verifying. But our X[N]OR signals read/write equality by remaining in its default state... so will always have a "write-complete" output except for the brief moment *when testing* (and the values differ). Thus, additional logic.

OR: note that what I really want is a relay that turns ON when the two signals are equal. Now we can't just throw a winding across them. But we can invert one signal at the input.

Handily, the read-back circuit is already out of the picture except when verifying... its output *floats*. That won't turn on our "inverter" relay until we're in verification-mode. AND, even more-handily than gating with the mode, this relay *can't* be active until the value is actually properly read-back, which takes some time.

So, now, we know that if that relay is on, we are in fact in "verification" mode AND its value is legit. Feeding that sorta signal into an XNOR with an inverted-input, and using the normally-open contact, then, can go directly to our "end-writing" relay... 

...which we no longer need, because that relay was normally-closed, to allow the "writing" relay to latch... and now our "values equal" relay is ON when equal, and OFF (normally-closed) at all other times.

Bam.

Major reduction.

But, one problem... our "inverter relay" connected to our read-back circuit remains off both when the read-back circuit output is floating and also when 0. Nope. But our Writing-circuit's value *never* floats under normal conditions, it's value comes from a SPDT switch which is either high or low (except when switching, which shouldn't happen *during* a write). So, placing our inverter-relay there, instead, (or using another pole with opposite wiring) assures that its output is always valid.

Then, swapping back to the read-back circuit, its value always being "valid" or floating, we can wire that directly to the X[N]OR relay-winding, and now that relay will only ever turn on (breaking the NC contact, stopping writing) when the data's valid, we're writing, we're verifying the write, and the read-back value is opposite the inverted write-value.

BAM. A shitton of logic removed, and no need for added delays or synchronizers to wait until the read-back system has valid data.

Tri-state FTW!

I gotta say, There are some impressive relay-projects out there, many here on .io. Some relay-computers, even. I never really considered 'em anything more than just a pile of gates implemented with relays instead of TTL... An impressive feat alone, but having gone down this rabbit-hole, I have a new appreciation for 'em.