https://hackaday.io/project/28345-floppy-bird/log/143840-wip-mfm-normal-diskette-data-storage

LOL.

So, the shortest single-polarity magnetisation is 2us, two MFM bits long, e.g. between MFM="101" where the new polarity starts immediately after the first '1' and ends immediately before the second... "10" representing two bit-durations of the same magnetization.

The longest single-polarity magnetisation is 4us, four MFM bits long. (Not shown in the diagram). in the pattern MFM="010001" from the data value "101"... MFM="1000" representing four bit-durations of the same magnetization.

These two limiting-cases, obviously by-design, satisfy both the serial-clocking needs as well as the inductive pickup's needs. The latter being most important for my new PWM-data-storage method.

Yeahp. I wrote that. More than half a year ago.

And... I kinda rediscovered the bold bit, the hard way, in October.

...

The other day I finally got back to coding. A key factor was replacing my constants and calculations, which originally used microseconds as units, with instead a new unit I'm calling PWM-Value-Ticks (pvt). Thus, soon, I can use multiple AVR-timer ticks for each pvt. The original design called for pvts that occurred at 16/us, which corresponded to one pvt per avr cpu cycle, when the timer ran with no divisor. Thus, 16 PWM values stored in 1us. 

But, since the latest conclusions that maybe 1/16 us resolution might be asking too much of the floppy hardware, I figured on running early experiments with scaled-back requirements, thus, e.g. 1pvt=3cpuCyc, etc.

This'd give a lot more fine control for experimenting as opposed to merely changing the timer's divisor. And, anyways, since I'd done everything in us previously, and relied on 16 timer ticks per us in some calcs who actually need a specific duration, changing the divisor wasn't an option, either. 

So, pvts it is for anything PWM-nibble-related, and us/ns for everything else (e.g. 0.8us max /WG->/WD).

And... we come full-circle to the bold bit... There really may not be much room for experimentation in the form of scaling back expectations, because, as I apparently was already aware of half a year ago, then had to rediscover the hard way, the inductive read-head surely places a limit on the length/duration of a single polarization. 

There's probably a small range of pvt-durations which will work at all. And the effect of longer durations will likely look the same as the effect of too-short durations.

It may be the only real option is to scale back not the density of PWM-nibbles, but the *number of values* per PWM-data-chunk, using the same timing (buffer durations) as the original design. E.G. a two-value system (as opposed to 16) would basically be within the same timing-constraints as MFM, and should work. Maybe then try a 4-value system. 

But...

This path goes back to original (us) times as originally intended, as opposed to pvts.

And, now, the math/constants need rewriting again, almost back to how it was.

D'oh!

And further, quite a bit of the as-is code is designed exclusively for a 16-value system, so got quite a bit of recoding (again) to change that.

Experimentally, it's *likely* 4us isn't the longest measurable single-polarization, just the longest *guaranteed* measurable. So, realistically, there are *several* factors needing "scaling-back" and experimenting. And, for some, "scaling back" may actually mean *increasing* flux-change density. Seems a bit counter-intuitive. But, I didn't just pull those original numbers out of my hat.

I suppose the next logical step, then, should be trying out a two-value system with the original mfm-compatible timings. That should function... once it's recoded. And all that other recoding for pvts...? Oy. PWM-Value-Ticks don't make an ounce of sense, here.

...

Realistically, I've run into scenarios like this a lot... basing constants and math on units, then later realizing I shoulda used different units. Maybe I should think of this sorta thing more like specifying measurements in a CAD system. You wouldn't specify the width of a doorway by measuring from the outside of the trim on the left to the inside of the trim on the right... wouldja? Not unless the doorway is crammed against a newly-installed wall on the right-side and the right-side trim's inside-edge is in fact now flush with the edge of that wall's sheetrock, butted up against it... and you weren't specifying the door-width, but the length of the piece of trim you need to buy to retrim the top! OY!