LOL, I was so proud of this project back then... 

And while admittedly my analog-design/understanding skills have diminished since then (to the point of barely even grasping how this works anymore), I can't help but feel like past-me cheated by using diodes! A *zener*, no less!

(Is it even possible, without? Dunno.)

...

I've plans for a binary up/down counter in another *very slow* project, so am sillily-contemplating daisy-chaining 8 (maybe 16) of these as a ripple-counter.

It would be *absurd* to do-so. But that project is absurd by intent... Though, mostly in trying to do things with as *few* components as possible, so this thing's excess of components (times 16!!!) would complement that in a strange way.

...

That project also requires an 8-bit (maybe 16) magnitude-comparator... Compare one byte/word to another, output which is greater on one of two pins. There's a 4000-series chip for 4bits of that, and it was quick-and-easy to get going. 

But, I was contemplating reimplementing it with transistors, or something similar, and noticed just how *huge* the internal logic in that chip is.

So, I started contemplating different ways of reimplementing it... And I think I came up with a circuit using 7 (or 15) XORs, and a bunch of diodes. The diodes are mostly for 'open-collector' OR gates, but also as, essentially, active-low open-collector [un]buffers with output-enables... So, [un]buffers with a "BLOCK" input... which, allows for essentially multiplexing all the inputs and passing-through only one (pair).

It's kinda groovy, but it also is a bit power-hungry, and slow... and... a *lot* of diodes.

In the process, I also discovered that XOR isn't really as-complicated a gate as I'd previously thought... just parallel an OC-NAND with an OC-NOR... which is even simpler by paralleling an OC-AND with an OC-OR, then inverting the output... Four diodes, a transistor, and a few resistors! Right???

Anyhow, before I confirmed my discovery I realized it was a LOT of diodes for 8-bits... And in the background I briefly (and somewhat begrudgingly, since I'd somehow had it in-mind that diodes and transistors were *required*) acknowledged how simple it is to make an XOR with a relay... Simply wire the two signals to the relay-winding. Done.

But I kept fighting with diodes and transistors, and it's not bad. And I think I could reduce diode-counts tremendously if I'd combined my output-enablable-[un]buffers with my ORs... instead of daisy-chaining them... (three-input OR?! Really? Heh... 8-input? That can't be possible, can it?! Sheesh.)

But I stopped when I realized the current design had something like 4d+1t+4d+2d= 10diodes and a transistor (which I guess isn't so bad, really) and numerous pull*down* resistors per bit... (and the tremendous amount of power it would take to "block" 7 of 8 330ohm resistors in parallel tied to ground. Not that I care so much about power-usage in a project as absurd as this, but that the input-signals just aren't capable of driving such a heavy load... (add a transistor!).

So, of course, maybe this could be redesigned with active-high instead of active-low, and instead of 330ohm pull-downs, I could use kiloohms for pull-ups...

But that's when I realized... Hey, there's *zero* requirement for diodes/transistors, here... [Somehow I think I had it in-mind that even though this thing is *slow*, this particular piece of it had to be faster than relays would allow? WHAT?]. In fact, the next piece of the system, following the magnitude-comparator, is *really* slow... we're talking on the order of half a second [minimum] to possibly many tens of *seconds*, depending on how big the difference between the two binary inputs.

And, sheesh... I mean, the whole point of this project *is* the fact of tying-together a fast system, making it reliant on a slow one, for its most basic needs. The Point is to make these operations understandable to a human in realtime. Y'all's fighting for gigaflops while this project is best-off running at FIPS (Fractions of an Instruction Per Second)!

So... a few milliseconds for relays to switch is a problem?

LOL.

So, then I worked-out the circuit, using relays, and... it took 5 minutes (vs the *hours* spent with diodes and transistors!). And all it takes is one DPDT relay per bit... And, actually, the lowest bit doesn't even need a relay. 7 (or 15) relays, total.

Sheesh!

(That's for the magnitude-comparator. Otherwise, I still need the binary up/down counter... which eventually led me to think about repurposing *this* project and its tremendous mass of circuit-elements... just to add to the new project's utter insanity).

But, driving relays from CMOS outputs... now we need transistors. And doing-so for our XORs means H-bridges! Yeah. That *could* be accomplished with one additional SPDT relay per input, but now we're talking 8bits*2 (or 16bits*2) 16 or 32 relays (well, 14 or 30... and driver transistors!) *just* to make our 7 XORs interface with the input-signals.

....

H-bridges... well, I mean, I could go the route of discrete transistors, but still we're talking at least 2 transistors per bit! So, (Oh, hey... I might be able to do something with a split powersupply? hmm...)... So, yahknow, comparing two 8bit values is 16bits... 32 transistors just to use relays? Hah!

But... I mean... This project has *zero* requirements... And, I happened a while-back to invest in a bunch of audio-speaker-amplifier ICs... (me? who seldom does analog? But they were SO CHEAP!) Which... I did, actually, once try (successfully!) to use as motor-drivers. If I recall, they were designed for car stereos, and have separate drivers for front and back... 4 h-bridges in each chip. 8bitsx2, 4 chips!

...

Ahhh, it's coming back to me... no, the 4ch chips are designed to output positive *and* inverted to drive a speaker from a single input... So, actually, we could only do two XOR relays from them. But I'm pretty sure I also got a similarly large supply of 2ch amps with separate inputs for each half-bridge... hmm...

Anyhow, this is all crazy. But I guess the point of the project has become a system that makes use of very dissimilar technologies for different subsystems that *could* all be (and usually are) made from the same technology.

Sure, why not?