that name... just now imagined, might just do the trick... (was trying to figure out what to demo with this thing)

Herein, I plan to document plausibly the most ridiculous of my endeavors, to date...

Wherein there are planned two subprojects to demonstrate a technique I've come up with for increasing the amount of data that can be stored on media such as floppy disks, and maybe extendable to similar media still in use today, such as hard-disks.

(It's plausible this technique already exists, but I have not read of it previously).

The first subproject will use this technique to store and play-back audio directly on a diskette using an unmodified drive and a handful of discrete components (comparators, mostly). No microcontroller is necessary for concept-demonstration, though may be added later for increased functionality.

The second subproject, and likely my most-ridiculous, ever, will use this new storage technique to use a floppy diskette as a framebuffer for an LCD.

Briefly: each track will contain an entire frame, refreshing the LCD once with each revolution, at 5Hz.

(160 images! Think: HyperCard, or maybe a digital picture frame).

...

A standard 3.5in 1.44MB diskette is recorded at 500kb/s, and spins at 300RPM, or 5 rotations per second, 100,000 bits per rotation... left spinning on a single track, those 100,000 bits repeat...

A 240x160 LCD has 115,200 pixels... it's like a sign or something.

(Actually, it has 38,400 three-color pixels)

A) the 500kbps data rate is a guarantee by design, and can likely be bumped up a bit, especially on outer tracks... so a 15.2% increase should be doable. That doesn't include invisible pixel-clocks, used by the "porches", but... worst-case we lose some pixels at the right or bottom... definitely feasible.

But That's Irrelevent because:

B) a different, and possibly new, technique of magnetic data-storage is proposed:

North...  _____________
South... /       \_\_\_\_______/
         |--2us--|-1us-|--2us--|

Floppies store data as magnetic flux transitions. The 500kbps limitation is due, largely, as I understand, to the minimum distance at which two "magnets" can be placed on the innermost track without repelling or attracting each other too dramatically as to affect the stored data.

The typical approach is to store these flux transitions at one of two locations, depending on whether the bit is a one or zero. Thus, data is stored such that each data bit occupies essentially the minimum amount of space which can accomodate *either* flux-transition mapping without affecting the next bit. 

What I'm trying to say is that every bit contains (or at least is big enough to contain) a flux transition in either of two locations, one of which always goes unused...

But it needn't be that way...

Imagine a digital oscilloscope... Say it samples at 100MS/s. Analog-to-digital converters that fast are typically quite expensive. So a trick often used is to have, say, two 50MS/s ADCs which are offset by 1/2 of their sample-period. Bam... 100MS/s.

Now look at it the other way... the ADCs aren't restricted to 50MS/s... they could just as easily be bumped down to 49.9999MS/s. It's not a factor of sample-rates divisible by 50, it's a matter of the resolution of the sample-clock. And the limitation of 50MS/s is merely a matter of the maximum number of samples that can be crammed into a second, put more clearly, a matter of how fast a single sample can be processed.

But those samples don't have to be evenly spaced throughout a second! One could just as well sample one sample at 1/50millionth of a second, and sample the next at 1/49.999 sec, thereafter (being nowhere near some multiple of 1/50mil).

Oy... bad explanation. Let's think about synchronous logic... say you've a synchronous counter chip like the 74163 (TODO verif sync)... its maximum counting rate is say 100MHz. That limitation isn't due to some magic with frequencies, but due to the minimum time that it takes for a clock-pulse to result in an output... a propagation-delay. So, as long as your clock pulses are no shorter than 1/100million second, they can be any length one can imagine... the first might be 1/100mil, the next 1/49.999, the next 1sec, for all that chip cares.

Why harping on this...?

Many things DO exist with such limitations... their limitations being dependent on Frequency, rather than what imma poorly refer to as propagation-times. E.G. the bit-rate of a UART must be constant, because the sender and receiver have separate clocks which must be presumed synchronized... Or, e.g. FPD-Link, which only sends a single clock cycle for every Seven bits... would be darn near impossible to send each bit with a different clock-duration...

But... the positions of magnets aren't limited to some discrete spacing... set on a table, as long as they are far enough away from each other not to interact (say one inch), the distance between two magnets could be 1.1in, 1.001in, or 100.

Ok. So, we're not limited to storing bits on a floppy disk at evenly-spaced 1/500,000 second intervals... we are limited to storing flux-transitions on a magnetic medium at no closer than 1/500,000 seconds... but they could be spaced at, say, 1/499,999 sec, or even 1/100.

(Note: this theory, that at the floppy drive/disk level the "bit rate" is not fixed by some sort of synchronized logic, shift-registers, etc. seems clearly-verified by the fact of precompensation, which is fed into the write-data input to the floppy drive as a flux-transition which occurs slightly out of sync with the 500,000bps clock...)

So, the idea is to use pulse-width-modulation to store data.

 _____________
/       \_\_\_\_______/
|--2us--|-1us-|--2us--|

Now, no transitions occur closer than 1/500,000 sec (2us).

During the 1us transition window, the resolution could plausibly be as high as the read/write circuitry allows.

For this experiment I plan to use an AVR's input-capture unit to determine the data-value... at 16MHz, sixteen PWM values should be discernable. At 20MHz, 20... let's math with the former.

16 values is 4-bits. 4 bits of data is stored in 5us. The original method was 1 bit in 2us... so we're storing 4 bits in 2.5 bits' space. A full data byte, then, is stored in the space of 5bits.

And now we've stored 160,000 bits per revolution... which might be just enough for our porches (woot!).

....

So... using an AVR at 16MHz... say we use three bits for each pixel and save the high-values to indicate e.g. hsync and vsync. Should be doable, 8 colors.

At 20MHz, 20 values could allow for 16-color pixels and still leave room for h/v syncs... but also requires color palettes which might slow down processing.

At 28MHz, a bit overclocked, 28 values, 27 colors and hsync...

vsync might be handled by the index-pulse output by the floppy drive.

....

Now we've got 160 frames or images to work with... (80 tracks, two sides)... what to do with 'em?

Originally I was imagining something like HyperCard...

(Maybe FloppyCard?)

But came up with the name FloppyBird, just now....

And... heck yeah... it might just be possible to throw in a sprite or two!

Of course the background graphics gotta be brilliant to justify a frame buffer... and... graphic-design ain't exactly my thing.

....

And, realistically, calling it a frame "buffer" is a bit misleading... the frames can likely only be written in one long burst, and in realtime... not certain, but I doubt the erase/rewrite process is precise enough to modify a single bit, thus sectors.

For writing the images, then, we need a source capable of sending data as fast as the pixel clock. 160,000 bits in 1/5 sec. 800,000bps. Via UART, that's a tall order (1Mb/s, with start and stop bits). And: the AVR has to be fast enough to both receive this info and convert it to PWM for writing... The sender can't get caught-up in task-switching, etc. so long that it misses a pixel. The receiver likely won't be receiving pixel data at Exact intervals, so will need a buffer and the ability to tell the sender to pause transmission... and has to be fast enough to handle all this... tall order for an AVR, but not implausible.

Taller order: my dwindling AVR supply consists of devices with USIs rather than USARTs... so... might be looking into the ft2232's SPI functionality... requiring custom software on the PC-side... (though, even with a uart, that'd still be necessary)

...

An easier proof of concept might just be to generate the frames on the AVR... which would severely limit the show-off-ability of the floppy... since the AVR would have to generate the frames at the same rate and raster-format as they'll be displayed... could just leave the frame "buffer" out of the picture. (Except, maybe, such realtime frame generation might leave no time for sprites and gaming?)

...

Inherent clocking:

Forgot to mention that...

random thought 2-6-18:

Could the write/read heads' offsets (in time) be determined such that a single 'nibble' in this format could be modified?

Single-bit manipulation seems utterly implausible in mfm, as even the slightest shift could make a '1' (01) look like a zero (10). 

BUT here we have: EVERY nibble is prepended with a rising-edge. The placement of that edge wrt the previous nibble is *only* dependent on the 'worst-case' of the previous nibble's pwm value occuring *at the end* of the cycle, and allowing for *enough space* to prevent that flux transition from interfering with the next (the 'start' rising-edge).

SO: if the system's accuracy is such that any 'start' can, essentially, reset the timer... then it might be possible to write single-nibbles, plausibly with minor offsets, and still read-back appropriately.

E.g. worst-case gives 2us between 'value' flux and next 'start' flux... but *could* be *any* duration, as long as the fluxes don't interfere... maybe 3, instead of 2us, would allow for nibble-writes...?

Maybe not individual nibble-writes, but small groups (kinda like sectors), BUT the key being that there is no need for a pll to resync with each 'sector header', as long as a previously-written nibble's 'stop' length can be extended for the next newly-written nibble's 'start' flux.

Key factor: spin-rates of different drives' (or temperature, write-delay, etc.) writing consecutive nibbles.... not *as* relevant for a one-off, but definitely for a 'standard'

Might be wiser to have two AVR ticks per pwm value... so maybe a 2us transition-window? 4bits in 3's space... 133,333 bits/rev