Part of me has gained quite a bit of interest in trying to implement this thing (at least read-back) with discrete logic, like TTL/7400-series.

Sync: There's no reason it has to be the same duration as a PWM-nibble. 4us seems better to me.

The key concept of the sync pulses is to make it easy to detect which falling-edge from the Read-Data pin corresponds to the start of the PWM cycle.

Here, for sync, the falling-edge pulses occur farther-apart than they would in a PWM-data nibble. So, 4us is plenty.

Clock-syncing: 1us is divided into 16 possible values... so 16MHz sampling, roughly. 

"Roughly" because, realistically, it'd be kinda absurd to expect a floppy to spin at *exactly* 300RPM, or even exactly the same RPM each time it's accessed. And, frankly, it's entirely possible the spin-rate may vary several times per revolution!(e.g. the disk is worn in a spot that drags differently on the read-head). So it's actually rather necessary to have some amount of flexibility in the reader/writer's sampling-frequency, which means somehow adjusting that frequency to match that on-disk.

I've been neglecting that part, for simplicity, assuming that the spin-rate on the same drive/disk will be relatively constant most of the time...

So, now, two potential branches for the course of this project. A) get it working as simply as possible... That was the original goal... And, part of the intent behind that is to demonstrate possibilities to those who may otherwise be intimidated B) essentially rebuild the entire floppy-system from scratch, for the sake of learning, I guess. E.G. I've always kinda wanted to figure things like PLLs out, at a low-level... Now I'm thinking about how that'd work... to synchronize a clock with a pulse that's 64x slower (if I use 4us for syncing)... I've a vague idea of a 7bit counter, a <=> comparator, and... what for actually generating the clock? I think the norm is a voltage-controlled oscillator... But, then, it occurs to me the same could be done with an AVR and the OSCAL register, realtime varying of the AVR's clock to match a varying-frequency external source... weird concept, but kinda intriguing, potentially very useful... And... not at all in-line with the TTL-idea.

I guess this is how my brain works, or doesn't.

Anyways, TTL-implementation is more a thought-experiment, for the time being. Actually, the whole project is, so-far... Been meaning to solder up that proto, and get coding, but it never seems like the right time/setting, these days.

So, 4us for sync-pulses, 6-bit counter. Data is only valid during the 1us window between 2us and 3us after the start of the PWM cycle... that fits within our 6-bit counter, as well. 

Now, here's a thing I'd briefly pondered in the past: After the Data-edge occurs, we really don't care where the next PWM-start-edge occurs. It just has to be at least 2us after the data-edge. Thus, our counter needn't go higher than 48... it'll get reset to 0 at the next PWM-start, whenever it occurs.

So, one potential benefit of this (dependent on the write-mechanism, and its alignment with the read-head), is the possibility to modify individual nibbles. Maybe a stretch, or maybe not... e.g. bumping the 'buffers' to 3us might allow for it, reliably.

Another potential benefit is increased capacity... if you're writing a lot of 0's, each nibble is only 4us, a lot of 0xf's would be 5us, each. Handy, then, for Write-Once, Read-Many drives, like a CD or movie. Not so much for read/write media.

In the case of this frame-buffer, it makes sense to keep every nibble the same length, for the sake of a steady pixel-lock (which isn't really necessary with this display). 

But, anyhow, with a counter limited to 48 or 64, not requiring a specific duration for every nibble, those options are possibilities. Simplify the thing, open new doors, I guess. OTOH, with specific-width PWM cycles, clock-syncing is inherent to every nibble... which ain't a bad thing.

Oh, I should mention, the idea of sync-pulses is to only use them (several, probably) once at the beginning of a long data-stream... E.G. immediately after the index-pulse. And, if I go the route of sectors, then once before each sector.

And, again, the main reason for them is to indicate which edges are which, clock-syncing was just a side-effect.

Yeahp.

I'm sure I had more thoughts, but I've lost 'em.

----

Oh... back-to-back data... yeah, that'd be hard to keep a clock sync'd to. but not impossible. Especially with regular sector/sync headers. definitely potentially useful for WORM drives... yahknow, where there's no PWM-start pulse. e.g. a 2us duration from the last value-pulse to the next indicates 0x0, and a 3us duration indicates 0xf. Nearly double the capacity, anyhow.