Yep! That sounds pretty impressive until you consider that v60 was from whatever date it was three logs back when last I coded.

Basically, in times like these, I tend to forget where I left-off, coding-wise, and re-entry is quite difficult for me. Usually it comes in one of various unpredictable forms. This time it came in the form of cleanup. "What the heck does this mess do?" "Ahhh, that's the write-routine... time to put all that in a function outside of main so I can see the whole picture." And then what's this mess *within* the write-routine? That should be a separate function... 

And now, I'd intended on refreshing myself on the big picture and instead did a little toward those ends, but mostly wound-up revisiting the write-routine in greater-depth than I'd intended.

Which is fine, 'cause frankly, it doesn't function; big-picture, write-routine, or read-back... who knows. This is the sorta project where anything and everything could be the culprit...

So, write-routine cleanup, and somewhere a weird thought: The *easiest* write-test is actually *really* simple, and already implemented: The "Sync" pulses are Straight-up regular-ol' PWM of a specific and unchanging duty-cycle and frequency. Increase that frequency (decrease the period), slightly, and you have a valid PWM-Nibble (0x8), repeating indefinitely with no (zero!) processing overhead.

DUH.

Remember, an "ideal" PWM-Nibble consists of TWO sequential PWM-peripheral cycles with different Periods of VAL and 16(?)-VAL... math to be done, and registers to reconfigure at every cycle! But VAL=8(?) gives the same duty-cycle for both... And now testing our read-back routine doesn't rely on a functioning write-routine! Ish...

So, I may've mentioned, previously, the seeming importance of the *shortness* of the time between pulses of /WR. This new test seems to confirm that. A PWM-peripheral period of 4us gives garbage, whereas 3us looks *very* promising. 

(If the readback function worked as-intended, anything longer than 3us should be considered a sync pulse, *no* data would come through, not even garbage. Because garbage comes through, it's clear the readback routine isn't filtering properly, which actually is handy here...)

The theory being that the inductive read-heads require regular *changes* in the magnetic-field, or the winding current will drop to zero, plausibly looking to the comparator/amplifier like a change (especially with external electrical noise, etc.).

3us seems uncannily short to me... RIGHT at the threshold of the design. If I recall correctly, each MFM bit is 1us long, and there's a not-uncommon case where up to three consecutive MFM-bits can be zero (no flux change for 3us!) So, seems like sensors' failing at 4us would be unlikely. But... who knows...

Regardless, recording a constant pulse-train at 3us appears to be working. Read-back results in almost zero garbage, clicking, noise, whathaveyou... which was previously quite dramatic... Now there's clear repeatability of read-back data on a track... And, dragging my finger on the spindle-motor appears to change the read-back values (as it should, slowing it down, slightly, extending those 3us pulses, slightly). 

It might actually be slightly-functional!