OK, but there's really no [easy] way to determine whether we're looking at the *start* of a PWM cycle, or the falling-edge of the duty-cycle, itself... because: every edge is stored as a falling-edge.

This doesn't matter for *audio*, because an inversion in the PWM output-signal results in an inversion in duty-cycle, around 50%... and *that* is nothing more than an inversion in polarity on the speaker-cone, which doesn't matter when only dealing with mono.

But for *data* (e.g. the image-frames), we definitely need to keep track of which falling-edge corresponds to the beginning of a PWM pulse, and which corresponds to the duty-cycle's edge.

I feel like I must've figured this out once before...

Best I can come up with is to align the PWM with the "Index" output (which occurs once every rotation). But, that may be iffy, as well... E.G. the Write-head and Read-head may not be perfectly aligned... in which case, writing at the start of an index-pulse may be read-back after! Oy! Then, of course, the odds of the "index" outputs on differing drives being perfectly-timed with the read/write-heads... Even less likely.

Some amount of reconstruction should be possible... e.g. let it run for several pulses, then figure out which edge occurs at the same period, then that's the PWM-start edge. But... well, anyways, it's getting a little more complicated.

An interesting artifact will occur when switching tracks... (e.g. data will be garbled while the head races to the next track, *but* the screen will most-likely continue to refresh with that garbled data since the uC will be regenerating the pixel-clock... but hsyncs will be missed, or even randomly-injected...) I've looked forward to seeing that. And with this new dilemma, it could be even more interesting (e.g. colors may be inverted for one frame, even after the read-head has stopped seeking).

Frankly, I consider these things to be one of the major driving-factors for this project... I already know the project should work as-planned, with maybe a few unexpecteds which can likely be worked-out... But these other things, probably not *useful* per-se, but hard to predict, so akin, maybe, to the draw to watching a flame. And sometimes these sortsa things wind-up being *very* useful... Moldy bread, yahknow? Moldy-milk, Moldy grapes, Moldy oats-grains-and-hops... Post-its! (oh, wait...) Once it's running, I'll probably spend more time looking into that stuff than actually making it useful (turning it into a game, etc.) If nothing else, maybe I could use it as a random-number-generator...

--------

Another idea, (I feel like I'm reinventing the standard method) is to have a "header" at the start of each track, immediately after the index-pulse. This'd contain a string of PWM-values with the same (not 50%) duty-cycle. Oh No! Wait a minute... It'd have to be *vastly-differing* duty-cycles, from one to the next. Then, use this time to look for the edges which are periodic, as described earlier.

The original plan was to use the "index" pulse *as* the Vsync pulse... Doing-so, here, wouldn't be so useful... Unless, maybe, I choose to use the trailing-edge for Vsync, and the leading-edge for beginning the header. Hmmm.

If that *doesn't* work, then we'd have a string of data that can't be used immediately after the vsync, which'd leave garbled pixels on the first row of the screen. (Which could be interesting, anyhow).

But, it could be that we're back to having a specific nibble-value to indicate Vsync. Not so bad, really. Better, probably, what with the alignment concerns.

And, again, I'm planning on storing 4-bits per PWM-value, that's 16 different duty-cycles within a 1us time-frame, which corresponds to our 16MHz processing-speed. (Or, plausibly, 16 values in 2us, allowing for some lee-way, in case the disk decides to spin at a slightly different rate from time-to-time; due to temperature, maybe, etc. Or different drives...). But, with these processing-speeds, it might be difficult to shove a color-palette in there, so I'd only been planning to use 8 of the values for color-data, and one for hsync... so there's plenty of headroom for other things (vsync).