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


  • Strike 2

    esot.eric6 days ago 0 comments

    ok, unanswered Q's from the last log... had to remember physics lessons from nearly 20(?!) years ago.... 

    If you cut a magnet, you get two magnets.

    The magnetizations are at an atomic or molecular level... each atom or whatever is a magnet, with both poles. This is demonstrable by, e.g. cutting a bar magnet into successively shorter pieces, all the way down to an atom-width, it'll still have a north and south pole (assuming the cutting process doesn't interfere!).

    So, really, the only field lines are those extending from the ends of the magnet. Those between the molecules are so close as to essentially not extend outside the magnet. Thus, those have no effect on the R/W head. 

    Thus a long string of consecutive "bits" of the same polarity look like a long magnet with constant field-lines extending from the *ends* and wrapping around outside the media, in air, before reaching the read-head... right?

    Note that the read/write head often has its gap filled with diamagnetic material to bend the field lines. Shown above is the write process. Below, the field-lines extending from the stored polarizations. Note, the short arrows in the media are Not intentionally drawn to have Any size correlation to the read/write head, nor to the size of a bit. Those arrows would more-accurately be drawn *tiny* in comparison, each, here, representing probably *millions* of similarly-magnetized/polarized particles.

    Flux, as I recall, is essentially the amount of field-lines (and direction) through some given area (e.g. the gap in the R/W head).

    Floppy drives detect *changes* in flux, rather than an amount or direction.

    It's impossible that a write-procedure could switch the direction of the electric current, and thus the polarization, instantaneously. "What happens here?"

    The disk keeps spinning, meanwhile the write-head is essentially Off, at some point, and likely for some time, before ramping to the other polarity. Imagine "crossover distortion" from linear amplifiers. Also contributing: when the write-head has too little current to actually change the magnetization--during the ramp--for some time on either side of the crossover.

    So, during the crossover/off time, the magnetic particles (that's the word!) on the portion of the disk spinning under the write head will not be written with any polarization. It will retain what was already there. (there is no "erase before write" procedure on floppies, unlike audio cassettes).

    AND Strike Two for PWM-Nibbles.


    During the crossover-time when written, the original polarization already on the media could be anything, could be noise, or could be same- or opposite-polarized from a previous write.

    If same-polarized, the read procedure will detect a flux change not where it was written, but some time *after*. And now our measured PWM duty-cycle has increased.

    If opposite-polarized, the read should detect the flux change when it was written (right?).

    And, then there may even be plenty of room for numerous flux-changes to be stored and detectable within that space... There, I imagine, the read-back circuitry probably filters out repeated changes, reporting only a single low /RD pulse... ("0.1 - 1.0us" hmmm)... at the first flux-change detected. Much like a debouncing circuit for a push-button.

    OK, so... I dunno how fast crossover is, but 1/16th of 1us may be asking a lot. So, it's likely my PWM-nibbles are being mangled here (as well).

    Plausible Mitigation-tactics?

    Write the same polarization *everywhere* on a track (erase) before writing data. Might be possible. But, now, the opposite-polarity case will read-back...

    Read more »

  • random Q's

    esot.eric10/16/2018 at 00:50 0 comments

    Does it erase first, then write?

    Apparently not. I guess since it's binary, it needn't worry about 'ghosting' of old data.

    Then what's with the "erase" head[s]?

    Those erase (maybe 'crop'?) the edges of what was just-written. "tunnel erase". Apparently the read/write head is slightly wider than the data-track.

    Are read and write on the same head?

    For floppies and older hard drives, it seems so. Though that same head may have separate windings for read and write, the actual "horseshoe" of the two electromagnets is shared. Thus, there's no physical displacement between read and write.


    Here's some references:


    Random unanswered Qs:

    How does it determine which polarization to write, when?

    Best bet: it just toggles... starting randomly, or maybe always starting the same. But the actual polarization at any position is irrelevant, as zeros are represented by no change in polarization, and ones are represented by a change (flux). Since individual bits are never modified, and everything happens in sectors, and since sectors always start with a long synchronization sequence, it really doesn't matter what polarization it starts writing with. 

    It's *highly* doubtful, to me, that it starts with whatever polarity was last-read... that'd be somethin'. But I'm pretty sure it takes a bit to switch between read and write, and by that time the head's already moved to the next bit. Further, it'd be plausible the old data would be more weakly-magnetized than the newly-written, even if the same polarity, which could be mistaken by the read-head/circuitry as a change-in-flux (one).

    (This doesn't help my sectorless-single-nibble-rewrite ideas, but that was a far-aside)

    BUT WAIT!!!

    The read-write head is, essentially, a horseshoe-magnet. The media is written in the gap between the two sides of the horseshoe. Horseshoe magnets have *BOTH* North AND South poles.

    A slightly different observation/question was answered (see Head Gap Width at: that the moving media receives the polarization from the trailing edge of the gap. 

    (Ahhh! That might help explain why it needn't be erased first, it receives the opposite polarization at the leading-edge and gets repolarized at the trailing edge.)

    But, then, when the write process completes, won't there be a flux-change inherent?

    Again with the fact of sectors written in one single pass, and a differently-defined 'gap' of repeating data written at both the beginning and end.

    BUT, this may have some relevance to PWM-nibbles.... to be pondered.


    What about magnetic monopoles? If the media is polarized by the trailing-edge of the horseshoe-gap, which is, say, South. And, say, the disk spins 1/4in, causing a North(?) polarization on the media for 1/4in... where is the corresponding South pole on the media? Wouldn't it have to be large enough, or strong enough, to match the total flux of that 1/4in North pole?

    Opposite side of the magnetic coating? (rather than the plastic)? But, nah... because Perpendicular Recording is a much newer feature... (TODO look up). And am pretty sure the head-gap (the two sides of the horseshoe) is parallel to the track... (gah! is Perpendicular Recording perpendicular to the track ON the track's surface as opposed to perpendicular to the surface? TODO: LOOK UP!)


    well shee-it... this can't be right... for longitudinal... then a flux-change would be measured at every head-gap-width *except* where two 'magnets' are butted against each other at the same polarity....

    Read more »

  • Bit by the Jit[ter]?

    esot.eric10/15/2018 at 05:13 4 comments


    How'd I forget Jitter?

    This, I'm pretty certain, is not typically specified in most era-datasheets. In fact, as I recall, it's [now] mostly only specified in *receivers*, as in "how much jitter will this serial-data input tolerate?" As opposed to "how much jitter is generated by this serial-data output?"

    Wherein, there may be a potentially fatal flaw in my design-intent.

    Which might explain why the best I got, last I coded, and recoded and recoded, was a bit of my recorded signal amidst a slew of "static."

    Last-coding-status: I was pretty certain my use of C, rather'n inline-assembly, was causing computational-overhead that required more time than the 2us buffers available on either side of the PWM-data edge. So, toward the very end of that coding-endeavor, only a few hours before the deadline, I looked over [most] all the relevant assembly-listings... and... to my surprise, it seemed there should've been at least a few extra CPU cycles that went unused. And, having slept like a sum-total of eight hours in the past three days, chalked it up to... 'k-den' and "not enough time to investigate."

    Thus, fate was the composer of my musical scores... Mostly-Static, sounding a bit like a metal band, maybe.


    So, What is Jitter...?

    Simply: It's a slight variance in the time when an edge occurs.

    Imagine a perfect oscillator alternating between high and low with perfectly square edges (0ns rise/fall time!) at exactly 1.0000000000000MHz. Jitter is the slight variance around the times when those edges occur. They should occur at exactly 0.50000000us, but more likely they won't, varying by some tiny amount, say it's only 1ps... Then some edges will occur at 0.499999us and some at 0.500001us, and every time inbetween.

    Overall, these variances don't add-up; they don't cause the perfect 1.00000000MHz oscillator to drift from 1.00000000MHz. And whatever's clocked *by* the oscillator is still being clocked at a perfect 1.00000000MHz.

    So, I guess, Jitter somehow averages out to 0... I'm sure I've read folks' trying to explain it that way. Or, maybe it remains mostly-constant... a constant 1ps shift wouldn't affect the perfect 1...MHz clocking.

    But, it's a problem when clocking and data need to be precisely coordinated. If your data edges 'jitter' too much, then they may make it appear the data bit belongs to the wrong clock pulse.


    I've gotten a bit sidetracked, and it's important to note that I'm certainly no expert on any of this, this is how *I* understand it.


    OK, so, with the 'constant' idea, earlier, it'd be easy to suggest that jitter could come from, say, slightly different wire-lengths between clock and data wires... And, indeed, that *may* be one source of jitter. Though, I'm not certain it technically qualifies, or whether jitter is some umbrella term encompassing all possible sources of... jitter...

    But, as I understand it, 'jitter' is less deterministic. Sources include things like external noise, temperature variances, etc.

    And, many sources are, I believe, a result of the driving circuitry.

    Now, here's where it begins to apply to my floppy/PWM-data system...

    Imagine, for instance, a typical inverter gate, e.g. 7404. Specs usually give things like tplh, tphl, tpd. The rise-time (tplh), the fall-time (tphl), and the propagation-delay (tpd). These numbers are spec'd as mins and maxes... and, for the most-part are considered somewhat stable, given a perfect power-supply, non-varying temperatures, etc. But, say your power-supply sags slightly because another of the six inverters in the chip is switched at the same time as the one you're paying attention to... Now the otherwise relatively-stable tplh of your inverter varies slightly. This gets fed into another inverter, coupled slightly differently to the power-supply, and there's a slight delay between when the first technically considers its output properly-switched,...

    Read more »

  • some notes on indiscrete timing

    esot.eric10/11/2018 at 01:11 7 comments

    In the project-description I try to explain the non-discrete nature of magnetic media, and do-so quite poorly. Here's a simpler example: 

    A 74595(?) shift-register can take in a serial stream of bits, and convert that serial stream into 8 parallel output bits. There are 8 discrete positions for a bit to be stored. 

    Similar to any digital-memory, like SRAM, etc. Each bit is discretely positioned on the output of some 1-bit-wide logic circuit, e.g. a Flip-flop (SRAM), or a capacitor tied to a logic gate (DRAM). Again, that same circuit is repeated for each and every bit.

    In the case of a shift-register, we essentially have an 8-bit SRAM whose input is serial and output is parallel.

    So, say you load the serial bitstream 01011001 into the shift-register's input, then the 8 discrete outputs will each show one of those 8 bits.

    But now, what when you change that input bitstream to have a tiny pulse of '1' between the two zeros? It's not like, suddenly, a new output circuit/pin will be inserted between bits 6 and 7 to show that '1'.

    This may seem ridiculous to harp on, but the fact is that magnetic media, signals sent down wires, even RF and optical systems are more-often-than-not treated as discrete-time systems just like that serial bitstream fed into that shift-register.

    That extra '1' bit, discussed earlier, is considered a glitch in most storage and communication systems. Similarly, any value-change on that data stream at any time *other* than those discrete bit positions... (TODO: timing diagram). These, too, are considered glitches in most current systems (aka jitter).

    Frankly, I think that's a tremendous setback to our technological progress (maybe that's a good thing?).

    Similar to that 'glitch', even more similarly to that jitter, is the PWM-system I've designed, here... Feeding that *directly* into a shift-register seems a bit ridiculous... It won't work *at all* with the original MFM or RLL system, its shift-registers nor timing constraints. But it could work with the same (slow) technology available at the time, and so much easier with that available today.

    Continuing with its seeming ridiculosity: For it to work properly fed into a discrete-time system like a shift-register (similar to the MFM design of the era), the PWM-Nibble--5us long, with 16 values stored in the middle 1us--would require a shift-register at least 48 bits long (more like 72!). And that shift-register would have to be 16 times faster than those in the original MFM/RLL system. Further, Only 16 of those 48 shift-register outputs would contain data. And that data, when packed in binary, would easily be represented by 4 shift-register outputs.

    Speed-wise, as described in the project description, this system *could* have been achieved with the slower technology of the era... Using similar techniques as a 100MS/s oscilloscope with 50MHz ADCs, alternately taking samples. Or, much easier, by using timer-counters to measure the width of the pulse... As I recall, even the original 74163(?) could run at 16MHz. But, either way, there would be quite a bit more logic involved, and that wasn't cheap in an era where a Floppy Drive cost $200.

    So, absolutely, this method seems *completely* ridiculous as a means of storing or sending binary data.

    Except that magnetic media, fiber-optics, RF, etc. are *NOT* discrete-time systems, despite regularly being treated that way.

    So, now we exist in an era where FAST DSPs exist, an era where FAST shift-registers can be packed in by the thousands in a tiny cheap piece of silicon... And yet, we're still treating things like magnetic media, optical media, and coaxial media as though they're discrete-time and we need to pack on them as many binary bits, in discrete binary forms, each occupying some discrete amount of time or space.

    I think we've missed something.

    This PWM-nibble method I've come up with may be still discrete-time, cramming 16 values in 1us. But, it relies *significantly*...

    Read more »

  • some photos, etc.

    esot.eric10/08/2018 at 14:15 0 comments

    Audio and code uploaded, see this project's "Files" section.....

  • It's On!

    esot.eric10/07/2018 at 20:08 0 comments

    It has been a very packed couple weeks getting this thing going... BUT it's going!

    Lest I fall asleep and forget to update, here's the latest:

    I'm now recording PWM-nibbles onto disk *and* reading them back!

    There's a definite 'thing' with trying to do so much simultaneously with such limited resources... Each microsecond has 16 clock-cycles for the CPU to work with... in 5us per PWM-nibble we need to do quite a bit. Writing a nibble, for instance, requires updating the AVR's PWM configuration *twice*. There's a bit of math to be done, and looping/tests... a bit of overhead that should probably be written in assembly... which I'm slow-to-remember.

    So, presently, I think we're not really getting a constant stream of data, there are probably some hiccups. 

    Hah! BUT... we don't Need a constant stream of precise back-to-back 5us PWM-nibbles, all we *really* need is precise timing between the start and "value" edges of the PWM cycle! The duration to the next nibble's 'start' is irrelevant! How'd I forget?! 

    Off To Work!

  • e.g.4: interleaving audio - 3 minutes on a floppy

    esot.eric09/29/2018 at 17:31 0 comments

    New idea....

    This part's been discussed in previous log[s], but a little background before launching into my new idea. 

    I'm not certain, but it seems feasible that individual PWM-nibbles may be rewritten. 

    This is exceedingly difficult with normal MFM storage techniques, in part because even the slightest shift in timing might cause what appears to be a different bitstream than intended. 

    E.G. (neglecting MFM's encoding for a second, and merely taking into account that each *data* bit is represented by *two* MFM bits): Say you have the data 10 00 10 and want to change the 00 to 10. Now the write-head is *very-slightly* misaligned (to the right) with respect to the read-head, and instead we get the pattern 10 01 00. NOT AT ALL our intended 10 10 10. That spatial-shift to cause that may be only 1/4th of a bit-duration, the data may in fact be recorded correctly! It's merely slightly-shifted. (TODO, draw some friggin waveforms!)

    (There are *many* other reasons why this'd be exceptionally difficult, but let's start with that.)

    However, These PWM-nibbles have a very large spatial buffer on the trailing-end, in order to assure no two flux-transitions occur too closely-together as to interfere with each other. That's the trailing-end's sole purpose. It contains no data, and its edge, at the end, is really indicative of the *start* of the *next* PWM-nibble. So, realistically, that buffer could vary in length and not affect the stored data.

    (Man, this could turn into a great write-up, with graphics... I think I did, sorta, in a previous log)

    So, with PWM-data all that matters is the temporal displacement between the rising-edge at the start of the PWM-cycle and the falling-edge inbetween two cycles.

    BAM: it might be possible to overwrite a nibble anywhere on-disk.

    Sheesh, I haven't even gotten to my new idea for audio-recording. That starts NOW:


    Each track spins under the head 5 times per second.

    PWM-nibbles are (presently) 5us long. 

    Somewhere in there I think that correlates to 200KS/s.

    Audio CDs are only 44.1KS/s... so we could easily store nearly a second of audio on each track at nearly CD quality.

    (Well, 4-bit, instead of 16-bit *technically*, but we're talking PWM, here, not Data, and there's nothing limiting it to 16 discrete PWM values *except* when used for *data*... And even there, I believe I'm being conservative. This then being somewhat of a discrete-time, analog-value system, when used for audio).

    OK... but how do we get 1 second of playback from a track which repeats itself every 1/5th of a second...? (Yahknow, obviously I'm trying to do this in realtime, no RAM buffer)

    So... simply, interleave PWM nibbles. The first cycle will store at nibbles 0, 5, 10... The second at 1, 6, 11... Third at 2, 7, 12...

    Which is really only possible (recording-wise) due to the huge buffer at the end of each nibble.

    It Might Be Doable.

    Now, how does this effect our simple playback circuit (previously consisting of nothing more than a 7474 flip-flop and a transistor connected to a speaker)? We'll need to add a counter 74163, I think... Two, actually (maybe two 4017s would be easier). An AND gate... (with output-enable?) And a capacitor to hold the value at the transistor's base. Hmmm, *plausible*, anyhow.

    Anyways, it's just another possible tangent. That'd give 80 seconds of recording time on each side, near CD quality, mono.

    Lessee, 44.1KS/s * 2Bytes (mono) = 88.2KB/s, 1.44MB per disk, I think that'd only be 16 seconds if stored normally...

    Of course what is this "near CD quality"?

    Well, if we neglect the analog nature of PWM, and go back to nibbles, each PWM-nibble is 4 bits of data, so, I suppose a slightly different system could be desinged using 4 nibbles to make a 16-bit sample... then we're back to roughly 1/5 second stored on each track, so a little more than 12 seconds(?)...

    Read more »

  • music contest. -- DEADLINE APPROACHETH!

    esot.eric09/23/2018 at 01:31 1 comment

    Update: "DO IT NOW." Deadline in less than 2 weeks!

    Further info/updates at the bottom.


    FloppyBird is a two-parter...

    The first, proof-of-concept, is to use my new PWM-nibble storage technique to store audio on a floppy disk. The planned 250 (as I recall?) KHz PWM for audio is probably a bit overkill, but it will prove the data-storage concept for the next part...

    The second part is using each floppy-track as a framebuffer for an LCD. The new PWM-nibble data storage technique developed in the first/audio part of the project will enable enough data to be stored on a single track on a floppy disk to directly stream an image from the disk to a raster-drawn LCD, in realtime. Each PWM-nibble corresponding to a pixel being drawn (prb 8-color, leaving other nibble-values for hsync, etc.). Since a floppy disk rotates at 300RPM, the track will be read, repeatedly 5 times a second, refreshing the TFT's image 5 times a second, until another of the 160 tracks, each containing a different image, is requested.


    back to the music part, since that's the contest du jour...

    I *might* actually get to this this month, maybe. And, I've a lot of ideas for taking it in directions irrelevant to the framebuffer. 

    E.G. each track could contain a 1/5th second repeating audio-sample, then each track (of 80/side) could correspond to a MIDI note, playable by a MIDI keyboard, etc. 1/5th of a second isn't much, despite far more than that in pure data-storage-ability, but I'm trying to keep this simple... or am I? Regardless, I imagine most effects to sound a bit like a bird chirping, so now FloppyBird has two meanings.

    E.G.2 A funky sorta long-duration playback can be implemented by tying the Step input directly to the Index output. After a track is fully played-back, it will auto-advance to the next track. Recording this is difficult, due to the (unmodified) floppy-drive's onboard circuitry (see previous log), and playback would have notable distortion every 1/5th second as the head [may never] settles into the next track. Though, I am curious to hear that effect. And the playback system would require nothing more than a handful of simple parts (no uC for playback! But still need one for recording. Bah!)

    E.G.3. (see the previous log) Microstepping could be a thing, audio could be recorded in a spiral... a uC is necessary... and for some weird reason I still insist on using parts from floppy drives, even though the drive circuitry itself will have to be modified. Simpler might be to replace some of that circuitry with custom stuff, dunno why my brain went the path of using *two* drives' circuitry. BUT: This path feeds into another separate project, which may prove useful in the field of data-recovery.


    So, IF I get to this project in time, there *will* be a uC, regardless of its necessity. MIDI, recording-timing, plausibly microstepping... AN alternative *might* be to use the two-controller method with the auto-stepping method. sheesh. Duh. BUT I don't have my stockpile of parts, so uC it is :/

    Anyhow. Got a lotta things going against me this month, project-wise... and to top it off, my laptop with all my tools and custom libraries won't power up. BAH! 

    MUCH THANKS to a buddy, here at HaD, (Buddy, wouldja like to be named?) who hooked me up with a custom-built "antPC" even more powerful, and far less power-hungry than the ol' lappy... Size and power are huge considerations, presently, and he solved 'em both, very generously.

    So, First, a few potential paths to getting back to uC programming ability, none particularly speedy nor appealing. Guess that's what I get for never getting around to uploading all of #commonCode (not exclusively for AVRs)  :/


    Read more »

  • Two Drives for hack's sake

    esot.eric09/23/2018 at 01:18 4 comments

    This thoughtpath is more of a braindump for future project-ideas rather'n directly-relevant to floppyBird... But, even floppyBird isn't particularly-relevant to floppyBird, since this project-page is kinda a two-parter, with multiple tangents, anyhow.

    A tiny bit of background:
    The idea, again, is to record audio [samples] directly onto a floppy-disk. As I've imagined, the entire [simple] system, record and playback, would require little more than a PC floppy-drive and some simple circuitry, no microcontroller.
    Playback from a single track/cylinder I've got down to a simple T-Flip-Flop, a transistor, and a speaker.
    Recording, though, is a bit more complicated, due to the controller built in to a floppy drive. This controller has some protection logic to prevent accidental overwrites, e.g. if you try to record on a track for longer than a single rotation. Thus, timing of a few write-related signals is highly important. I'd thought it was only feasible with a microcontroller, but I recently had an idea.
    If the controller used for writing was unaware of the 'index' pulse, and maybe some other signals, it would have no reason to go into what Imma call 'protection', and, thus, timing isn't critical.
    One thought: Use a separate controller board, from a second floppy drive, which is *not* connected to the index sensor, nor the spindle motor. At that point, the controller might as well think the disk's track is *huge*, or even linear (like a tape). Thus, recording could be performed without regard to timing.
    Index-pulsing is still useful, however, since a simple way to record/playback from *multiple* tracks, sequentially, is to tie the index output to the step input, making it auto-advance with each rotation, kinda like a CD or record (LP, 45, etc.).
    Thus, using *two* controller-boards for recording: one handles the waveforms written to the disk, the other handles stepping through tracks and rotation.

    As an aside, this may also benefit my microstepping idea from a while back. (Probably discussed in my KayPro Floppy Recovery project).
    Microstepping the read/write head may be possible with precise timing to the Step/Direction inputs. The Problem, however, is that each change to Step causes the floppy controller to wait for the head to settle into position on the new track before reading/writing is allowed. So, microstepping *between* tracks would cause the controller to continuously *block* reading/writing. So, keep the read/write controller separate from the step/rotation controller, and it might just be possible.

    (Microstepping between tracks is an idea I had for attempting to recover data from old disks which may have warped over time, causing oblong or off-center circular tracks. This effect is more common on 5.25in floppies whose circular spindle-hole may've been stretched by many insertions over the years.
    But, microstepping in this case, for audio recording/playback, might be quite handy, as well. This'd allow a spiralling track, rather than dozens of concentric tracks. Thus, playback/recording would be uninterrupted with each rotation.
    And, yes, I'm very aware that *without* microstepping, any audio recorded/played-back will be at the very least distorted with each track-advance. Thus, an idea, presently, to use each track as a repeating audio sample, 1/5th of a second in duration... selectable via MIDI)

  • so, technically...

    esot.eric05/07/2018 at 00:33 0 comments

    a normal 3.5in floppy disk holds 2MB. That's not due to rounding.

    The disk spins at 300RPM, thus 5 rotations per second. The data-rate is 1Mb/s... but that's MFM bits, two of which make a data bit, so 500Kb/s of data-bits. Thus, 100Kb fit on each track, or 12.5KB. There are 160 tracks: 80 cylinders, two sides... 2 mega bytes.

    1.44MB for storage is due to formatting. Sector-headers, CRCs, and a few other things. Most computers are capable of different formatting, at the hardware level, but software doesn't usually support that by default. Thus, it's more than possible to cram more than 1.44MB of user-data on a disk, but less than 2MB, by using a different format (fewer and larger sectors means fewer bits wasted on headers, more for data), *without* using compression.

    But all that's moot to this project.

    This project replaces MFM-bits with PWM-nibbles. Each MFM-bit is 1us long (1Mb/s data rate), each data-bit, encoded in MFM, is 2us long.

    Each PWM-nibble, as I've currently defined it, is 5us long: four bits of data gets stored in that space. 

    Thus, in MFM, 5us would contain 2.5 data-bits, here it contains 4.

    That's 3.2MB per disk, vs 2MB. Of course sector-headers can be equally-relevant in decreasing the capacity for user-data... but I see no reason why it would be more overhead than on an MFM disk. 

    That'd make the user-data storage-capacity of a PWM-3.5in floppy 2.3MB vs. an MFM-floppy's 1.44MB.


View all 18 project logs

Enjoy this project?



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

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

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