Use a floppy-disk as a multi-frame-buffer, store audio-samples, and increase capacity to boot!

Similar projects worth following
Using PWM, rather than MFM, to store data on magnetic media, I believe it possible to increase the storage capacity dramatically without compromising data-integrity. With a simple 8-bit uC at 16MHz, 8 bits could be stored in 5 bits' space!

A single track, then, contains enough data to be used as a frame-buffer for a small LCD. 160 tracks makes for a digital-picture-frame, something like HyperCard, or even short videos.

But first, I'll store audio-samples, 80 tracks per side is perfect for a MIDI controlled synth-patch, etc. Yep, it's a bit crazy.

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... /       \_\_\_\_______/

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...

Read more »

Voice 003_002.amr


amr - 156.85 kB - 10/08/2018 at 14:04


Voice 003_001.amr

Full Seek/Write/Boop/Boot

amr - 278.41 kB - 10/08/2018 at 14:04


Voice 002_001.amr

This is data read off the floppy, *NOT* stepper-music. You can hear stepping in the background. Original composition by fate.

amr - 195.88 kB - 10/08/2018 at 13:47



code! Not Particularly Functional, but hey, it makes noise!

x-tar - 330.00 kB - 10/08/2018 at 13:28


  • Of course she did it!

    Eric Hertz10/07/2023 at 03:24 0 comments

    This is pretty much exactly what I'd been planning from the very start... (minus the reverb)

    I'll have to look into it more to see how she deals with the time it takes to step from one track to the next... I guess it's only a few milliseconds vs a half second per rotation.

    Also, since she's accessing the RW heads directly, (if I understand correctly) there's no problem with the write-gate, which prevents writing over the beginning of the track... and thus *stops* writing immediately when the index pulse comes (which would otherwise be fed back to automatically step to and continue recording onto the next track). One of those things that I ran into as a result of scaling up my original plan to digital/PWM rather than just going with the original idea of hooking the heads directly to a tape player. Heh. (the plan, there, was that I've never been particularly good at analog, so why not use something designed for the purpose of reading a magnetic head, and just electrically change out the head mechanism?)

    What I don't understand is how it's possible this vid is 14 years old and I never heard about it until now... As a passing thought in a Friggin HaD podcast, to boot. Do you have any clue how many times I searched for this since, oh, probably 1999 when I got the idea?!

    She even took it to the MIDI controlled sample-per-track idea. Sheesh. Yeah, that was in my plans, too. (BTW, which'd be a bit like a monophonic melotron, hmmm). But, doing-so with a hard disk... I dunno, Jerri... They spin *way* faster than 1/2sec per rotation... Though the autostepping idea used here with a floppy could probably be done with an MFM drive... though, as they get rarer and rarer, that'd be a bit of a shame unless it was already broken...

    TODO: there are other vids, too... probably some docs to look into.

  • Floppy audio player

    Eric Hertz05/27/2021 at 18:34 0 comments

    He did it!

    It differs greatly from how I intended to do-so, but quite impressive.

  • Digital Audio on VHS

    Eric Hertz04/27/2021 at 18:50 0 comments

    Around 22min in he shows the digital data on a TV... and...

    Frankly, I'd suggest each scanline appears to be made up of 7 PWM-nibbles. Could it be?

    I can't recall exact specs, but composite is often captured at 640x480, and as i recall it's actually more like 512 high, so lets go with 480. This thing records at 14bit, 44.1Ksps. TV's 30fps(?). Stereo.

    So, 44100*2*14=1,234,800bits/sec


    Hmmm, doesn't seem right...

    /7=12.25 bits/bar yeah, no... 4870 positions/pwm. Nope.

    But, there's black and white, so that'd remove A bit!... still 2400 positions/pwm, nah.

    Though, another thing maybe considerable is that even though the pixel resolution may be lower than 640/row, the actual signal is much higher in resolution for storing color info. Still, 640*3=1920... still not enough resolution for even one pwm-11bitter.

    So, say it used my pwm nibbles, 86bits/scanline / 4bits/pwm-nibble = 21.4 pwm nibbles per scanline, say each was buffered by start/stop of equal length: 16 values*3=48 is how many "pixels" each pwm-nibble would take... *21.4 nibbles =1027pixels per line. Which might just be doable... shrink the start/stop, consider the rgb*width... doable.

    So, I guess this thing doesn't do that. The data must be in the "snow". I dunno what those vertical bars are, then. But they do seem to get wider at higher volume. And, interestingly, the actual audio can be heard noisily through a regular VCR, which is kinda what I'd've expected if something like pwm-nibbles were used (pwm is how audio is stored on Video Discs). But, who knows how they encoded the signal.

    A somewhat fruitless venture down this rabbit hole with me, eh?

  • Single Edge Nibble Transmission

    Eric Hertz04/12/2021 at 04:33 0 comments

    I haven't read this yet to confirm, but this sounds VERY MUCH like my PWM-Nibbles planned for this project...

    I did, actually, come up with my idea on my own, based on the concepts I'd learned about floppy data storage in my efforts to recover data from an old floppy... that project is here, too. But linking is flaky.

    Anyhow, TODO for me...


    It crosses the blog again... and some more thorough documentation seems to confirm it's nearly identical...





    I did, in fact, come up with this idea as a result of learning about something dang-near completely unrelated; MFM encoding used on floppy-disks, as a result of trying to come up with a way to work around the limitations of the density of storing magnetic flux changes on a material.

  • Nice hack

    Eric Hertz07/17/2020 at 23:12 0 comments

    Also, a pretty thorough/informative write-up... Dude uses a video-controller to generate a serial data stream to be written to disk. 

    For some reason this reminds me of my trick in avr-lvds-lcd, which uses PWM to generate serial data packets to drive pixels on an lvds/fpd-link LCD.

    I guess for FloppyBird the main takeaway is the nanosecond-positioning of flux-reversals.

    Though I also dig how this hack is kinda like the exact opposite of FloppyBird; he uses a display controller to write to a floppy disk, FloppyBird uses a floppy disk to control a display.

  • Floppy Audio!

    Eric Hertz02/07/2020 at 22:17 4 comments

    Updates at bottom...

    Har Har Har

    It's kinda funny, really... basically just storing an URL. Sure, why not, eh?

    Kinda makes me ponder how many such *tiny* pieces of information might be useful in separate containers like this.

    On another note: I should maybe consider breaking this up into two separate projects. 

    Audio-storage is the first plan, and pretty much always has been. The original plan was to store it in analog, maybe even using an old cassette player for the electronics.

    This project-idea came around a bit more like a laserdisc; wherein the audio samples themselves are analog [in value] but discrete in time. I kinda dig that concept; it's quite a rare merge of the analog->digital crossover era. 

    The only other such example I'm aware of is an analog delay chip, often used in audio effects [e.g. echo]; it stores analog samples in a line of capacitors, and passes them down the line. A bucket-brigade of sample-and-hold circuits.

    I take that back, actually the concept is still quite common, e.g. CCD[?] camera sensors; a discrete number of pixels, yet the pixels themselves are analog.

    But, for long-term storage? Laserdiscs is all I can think of.


    Storing audio on floppies is well-thought-out 'round this project; one of the bigger issues is how to playback in realtime without a noticeable skip every 1/5th second during track-change.

    This project has been about how to use *unmodified* floppy drives in new ways; but that's a bit limiting for the original project idea of storing audio.

    Here's a just-now new idea toward that end which doesn't fit this project:

    Read/write heads have a "tunnel-erase" head. The idea is to have an empty/blank "track" between each data track so that two data tracks don't overlap. So whenever data is written, immediately after the write-head writes that data, the slightly-shifted "tunnel erase" heads erase the edges of the newly written data.

    Now: with microstepping of the track motor, data [audio] could be written in a spiral. And if those tunnel-erase heads could be *read,* [especially if they're wired separately!] then we could use them to guide the microstepping during playback! Like the groove on a record. Or like a "line-following" robot. [I think CDs might do similar?]

    That, though, would require floppy-drive modification; same hardware, different electronics.

    And, maybe even, they could be used in different interesting ways, like storing the audio on a spirograph pattern... hmmm.

    [Though, similar might be plausible with just the read-head, e.g. moving the track-motor to get the highest amplitude, especially with a carrier or *additional* wave, hmmm]

    Heh, here's a weird idea, a wave outside hearing range, constant amplitude/frequency, [cassettes do this part to keep the gain during quiet parts], but, where the stored audio only contains low frequencies, the "feed" [floppy spindle motor] could be slowed! Hmmm... 


    Random notes:

    1 7/8 in / sec

    ~280 ft -> 30min/side

    1500ft of groove



    765 rotations / side ! 

    765 "tracks"?!

    Ok, maybe not re: storing an lp's worth of audio on a slow-spinning floppy, unless we slow it to 3RPM, hah! [Might be an interesting controls challenge!]

  • How it works

    Eric Hertz12/11/2019 at 03:39 0 comments


    ... The floppy disk is spun by a drill, which causes the data to fly off the platter and onto the screen ...

    That's pretty much exactly the goal.

  • excellent info

    Eric Hertz10/13/2019 at 22:29 0 comments

    This floppy drive is made of mostly standard parts... its functionality, down to the read/write amplifiers, is clearly described.

    Note, however, its formatting is *very* different from a standard PC floppy. 

    From a quick-glance, this drive seems to store data bits directly-serially. No MFM, FM, etc. A '1' bit is encoded by a change in flux, while a '0' bit is no change. [Maybe it uses whatsitcalled, where data bits are encoded such that consecutive zeros are never encountered? But, no, it refers to 8 data bits... hmmm].

     Further, it doesn't appear to store *any* clocking data on the disk, relying on a perfect 300RPM spindle rotation, storing bits [actual data bits] at around 1MHz. I say "around" because it actually stores bits denser on outer tracks, which means changing the clock frequency.

    Again, *very* different than most floppy drives I've encountered. I'm a bit surprised it can even function. Do I have this right, or does the counter divide the clock further? 1Mb/s, 300RPM... 300/60=5 rotations/sec, 1/5=200kb/track 35 tracks, 7Mb/8=~1MB... seems a bit high... maybe that 7493 divides the clock. 

    Still, this system relies on near-perfect 300RPM, which is accomplished via DC [brushed?!] motor and a tachometer/feedback-loop... which... I'm not saying 300RPM couldn't be maintained, but we're also talking about a motor/tach combo tied to the spindle via belt, and also talking about a brushed motor, with a commutator and varying power at different rotational angles... I mean, WOW! 300RPM, *constant* throughout a rotation!

    And, frankly, throughout *multiple* rotations, as it reads multiple sectors?! There must be more to this. Resynchronization at the bit-clock level [maybe via index?]


    Anyhow, it suggests many things in favor of Floppy-bird...

    First-off, an idea how read-amplifier circuitry works... this, combined with the seeming fact of multiple-'0's/varying-flux-transition-densities in this system may give some insight into whether my pwm-nibble scheme with its varying flux-density is even feasible [maybe at a much slower rate/data-density than originally planned]; as I recall, I last encountered randomish read-back data from what appeared to be related to too-distant flux changes causing automatic-gain to amplify minor flux variations within a single polarization along the track. While that *may* be the case, here we have a system-design that doesn't seem to have automatic-gain, yet still has widely-varying flux-transition-density, which could rule that out. 

    I have other reasons to rule that out, as well, such as consideration that my PWM-nibbles were designed to fit within only a *slight* stretching of the timing-specs of the drive/disks I'm using. And, further, that a 1.44MB floppy drive is also capable of using 720KB disks, whose flux-change-density [vs. Time] varies further-still. [However, I hear the magnetization of the two varies].

    Also, flux-changes can result in a very short pulse in the read-coil's voltage, followed by a comparatively-long 'zero'-output before the next change.

    (From an excellent resource:

    However, there's also mention that higher densities may be less-defined, which may require more active sense-amplifier circuitry [automatic gain/offset?], and combining that with MFM's assuring *maximal* density... well, it's still kinda up in the air.

    I'm pretty sure I gained more insight than this from that service manual, but I'm blanking, now...

  • TODOs, revisits, etc.

    Eric Hertz01/03/2019 at 05:42 0 comments

    6-10-19: PlottyBird!!!

    3-2-19: Interesting coincidence: Van's OBD looks *VERY* similar to PWM-Nibbles, lotsa ramblings comparing/contrasting:

    also, did I not link the dude with an opensource flux-logger? He's using timer-input-capture... must be at:


    Original post:

    Sometimes it's useful to read through old logs... (how'd I forget?!)




    (more to come, I'm sure)

  • v61

    Eric Hertz01/02/2019 at 09:10 0 comments

    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.


    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!

View all 38 project logs

Enjoy this project?



Ken Yap wrote 10/13/2019 at 23:58 point

I just replaced the DVD-RW in my PC with one given to me by another "dumpster harvester". The replacement drive is almost new; it probably saw little use in an office as people seldom read anything on their DVD drives these days.

I'm the only person I know who actually wears out DVD-RW drives, doing an automated backup every Sunday, and the odd archiving of accumulated photos (in addition to archiving on (duplicated) portable hard disks and the cloud). I may not ask for a DVD-RW for my next PC workhorse build, or at most buy a portable drive.

At some point, probably when my stash of CD-RW and DVD-RW discs run out, I'll have to abandon the medium, like I did to floppies a couple of decades ago. Then I copied every floppy I had onto a couple of CD-Rs and consigned the floppies and drives to recycling heaven. It is nice to give a friend an encrypted DVD with my files just in case my house burns down, but I guess cloud backup can cover that eventuality.

  Are you sure? yes | no

Eric Hertz wrote 10/14/2019 at 00:11 point

thanks. That means a lot.

  Are you sure? yes | no

Lee Djavaherian wrote 04/24/2018 at 00:23 point

You have many interesting projects, and your writing style is really enjoyable to read.  I like the ways that you re-use older tech, the techno-archeology you perform, and how you also change gears and publish those inexpensive lifehacks like the automotive repairs. (By the way, I also have a makeshift heater-core bypass in my car, and it's a true Apollo 13 cabin experience in the winter! And I have a Marantz 2230 that I need to fix, but I digress...)

This Floppy-bird project, though, is really interesting and several orders of magnitude more complex; I keep coming back to it for some reason--it sticks in the mind--something that shouldn't exist in our reality, but something that I would like to see exist.  I've e-wasted so many of those drives years ago and felt bad about it every time. 

It is fascinating how old and new tech often have these weird similarities that sometimes allow their mystical conjunction, so to speak, that "sign or something" you mention.  The tech you are combining are shifted slightly in time and purpose such that they can't be connected directly, yet they share the unifying element of the picture frame, which they can all deal with in different ways.  It's great to see you engage these kinds of alignments and perform further exploration, and you are going pretty deep into floppysophic territory on this one.  Impressive.

  Are you sure? yes | no

Eric Hertz wrote 10/14/2018 at 06:17 point

Wow! In a strange temporal-twist, I've just stumbled on this comment half a year after its posting. This really means a lot to me. Thank you, my friend!

  Are you sure? yes | no

zakqwy wrote 04/12/2018 at 13:35 point

man I miss hypercard.

  Are you sure? yes | no

Eric Hertz wrote 04/13/2018 at 05:39 point

Those were The Dayz!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates