...worked surprisingly well, considering how convoluted the concept and the code.

I've been hacking at this thing for what seems like ages... I think I said that once before, and *that* seems like ages-ago.

This thing is *huge*. I can't believe I wrote all this code.

Currently, got a bit side-tracked...

I *still* can't get it working through the one-shot circuitry 9 times out of 10, even with it in *bypass* mode. Absurd: bypass-mode sets one input of an AND gate high, so that the other input goes in and comes out just like it went in. Physically bypassing that gate, by pulling the chip and shorting its input to the output, works.

I, once, figured there was something to do with code--buried somewhere I couldn't find--that set *another* pin too closely to the passed-through signal... and that the passed-through signal was being delayed slightly by the gate, which somehow allowed an overlap. But, I've gone over this code with a fine-toothed-comb, and now understand that part of it inside-and-out (again). I've also rewritten a bunch of it to make it more clear and even less-likely to have issues due to gate-delays.

I've 'scoped it, I've done durn-near everything I can think of. Still ain't working through the bypass gates. ONE idea I have yet to test:

There is another AND gate, in the chain (which works when the *other* AND gate is physically-bypassed) whose output is *disabled* by having one input tied-low. The other input to this gate could *float*, briefly, at times... And the amount of time it floats *might* be a tiny-bit longer, due to the "one-shot bypass" AND-gate. Or something. So, I've actually been looking into the specs of TTL ICs...

The idea: It's *plausible* that a floating input on an AND gate, even when the *other* input is tied-low, *might* allow for a high output.

Theory:

TTL AND:
In0   In1   |  Out
-------------------
0     0     |  0
0     1     |  0
1     0     |  0
1     1     |  1
0     Float |  could be 1 ????

Looking into the ancient 1980's data-sheet, which shows the internal schematic, it might actually be possible.

I don't exactly understand the logic of a "dual-emitter" BJT, but maybe...

So, I might end up trying this out, throwing together something on a bread-board with a slow sine-wave input... Seeing whether there're any glitches on the output (it should *always* be low, logically, right?).

I've a few other ideas as to why the bypass circuitry doesn't work, but most aren't being clearly-corroborated... (the power-supply/voltage-regulator might be having problems with the excess current-draw? 'scoping looks alright.)

And a few other tests to try (the obvious one being to set-up read-back of the written-data, for verification...)

It's just so strange.

In the meantime, I've been avoiding the verification-step, not exactly sure why... (now that I re-understand the WRITE code, inside-and-out, updating the *ancient* READ code shouldn't be too difficult).

In my avoidance, looking into other things, which are plausibly only *tangentially* related to the bypass-problem...

Now I'm revising the code for the cursors...

And have run into another *entirely weird* non-functionality.

As @davedarko and I have agreed... maybe this just ain't the month for development.