Close
0%
0%

Floppy-bird

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

Read more »

Voice 003_002.amr

JustTheData

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

Download

Voice 003_001.amr

Full Seek/Write/Boop/Boot

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

Download

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

Download

flopAudio59.tar

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

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

Download

  • Nice hack

    esot.eric07/17/2020 at 23:12 0 comments

    https://hackaday.com/2020/07/16/a-lowly-8-bit-micro-busts-copy-protection-from-the-16-bit-era/

    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!

    esot.eric02/07/2020 at 22:17 4 comments

    Updates at bottom...

    https://hackaday.com/2020/02/07/music-player-erected-from-floppy-disks/

    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:

    https://en.m.wikipedia.org/wiki/Audio_tape_specifications#Compact_audio_cassettes

    1 7/8 in / sec

    ~280 ft -> 30min/side

    https://en.m.wikipedia.org/wiki/LP_record

    1500ft of groove

    1.8sec/rotation

    ~23min/side

    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

    esot.eric12/11/2019 at 03:39 0 comments

    8:23

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

    esot.eric10/13/2019 at 22:29 0 comments

    https://www.google.com/url?sa=t&source=web&rct=j&url=ftp://www.zimmers.net/pub/cbm/schematics/drives/new/1541/1540-1541_Service_Manual_Preliminary_314002-01_(1985_Jan).pdf&ved=2ahUKEwja48SMkZrlAhVDnp4KHelTCdYQFjABegQICRAC&usg=AOvVaw1UQWKECdi5k6xhCb7yV4kw

    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: https://info-coach.fr/atari/hardware/FD-Hard.php#Sense_Amplification_and_Conversion_Circuits)

    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.

    esot.eric01/03/2019 at 05:42 0 comments

    6-10-19: PlottyBird!!!

    https://hackaday.com/2019/06/08/1980s-plotter-plays-flappy-bird/#comment-6155564

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

    https://hackaday.io/project/162883-hackavan/log/159811-obd-oh-blah-dah

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

    https://hackaday.io/page/3986-floppy-shenanigans

    ---

    Original post:

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

    TODOS:

    WRITE METHODS:

    https://hackaday.io/project/28345-floppy-bird/log/143398-pwming-2

    4us:

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

    (more to come, I'm sure)

  • v61

    esot.eric01/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.

    DUH.

    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!

  • Neuron-Firing?

    esot.eric11/17/2018 at 22:21 2 comments

    I've only a tiny understanding of neurons, but as I understand a neuron takes in many [analog] inputs and "fires" when some threshold is crossed. The output is, essentially, binary... 'zero' most of the time, then 'one' very briefly during the 'firing' of an impulse. 

    Anyhow, I think what it boils down to is the *timing* of those singular impulses ('ones'). 

    And... that's *exactly* what this storage-method is all about! Output consists of two impulses, the time between determines the value.

    Have I inadvertently stumbled on neural memory?

    (Thanks @Lee Djavaherian for the comment in the last log!)

  • Light-bulb current-limiter... Incandescent RAM?!

    esot.eric11/14/2018 at 20:34 12 comments

    As part of my house-battery charging system, I thought maybe to use a light-bulb, instead of a resistor, as the current-limiter. 

    Pretty simple, place lightbulb in series between voltage-source and battery.

    The idea came to mind as I sat outside a physical electronics-parts store (they still exist!) contemplating worst-case scenarios and the supplies available. 80W, I determined, through something like 0.1ohms. None-a-dem resistors were *even close* to that wattage. 

    But, yahknow, lightbulbs are darn near a wire and capable of handling 100W. If powered normally, there must be *some* resistance, otherwise they wouldn't stop at 100W! But, last I recall measuring with a meter, probably 15+ years ago, the resistance was near zero. So there must be an I-V curve, their resistance must increase when powered... right?

    And, that's exactly what I'd want; a higher resistance when my battery's really low, so my charging circuit won't blow my fuse, and a lower resistance when the battery is nearly charged, to cram in as many electrons as possible (again, without blowing the fuse).

    Cool. And after finding I-V curves showing just what I'd guessed, I had it in mind to see if anyone's tried it... Sure enough. It was actually pretty common back in the day. And there's even a video of a dude charging a car battery from 240VAC, rectified, with nothing limiting the voltage/current other than a series lightbulb.

    Not *quite* what I had in mind, but concept-proven.

    I started thinking about it, though... 

    The I-V (V-I?) curves didn't show extreme cases, extrapolation was necessary for e.g. the resistance of a 100W 120V bulb running at 12V (nevermind the ~2V difference when the battery's nearly full). So, it comes down to buying a bulb and measuring.

    Figured this 3-way bulb would give me more options... (4!)

    Measurements: ~10ohms and ~20ohms. Much too high for my needs. But, V=IR P=VI=V*V/R, R=V*V/P=120*120/100=14400/100=144 ohms vs 10 measured, *definitely* not a resistor!

    Allegations are that the resistance increases due to heat... so, realistically, an I-V curve is a little misleading.

    This be a strange device... Not a resistor, not an inductor, surely not a capacitor. What is it?

    And what when 80W is run across it, but at a much smaller voltage? Maybe not possible, anyhow, its resistance would increase with the heat, thus the voltage-drop across it would also increase, and ultimately wouldn't allow high wattage at a low voltage.

    Anyhow, I kinda thought, hoped maybe, the curve would swing down a little further, on the order of 0.1ohms woulda been nice. Am thinking a 12V bulb might have a lower resistance. Those high-wattage, low-voltage bulbs have beefy filaments. (How much light actually escapes a chunk of metal that thick?!). 

    And, this setup is probably much more like those of yore, when perhaps charging 12V car batteries from 15V-20V generators (depending on the driver/traffic) might've been accomplished with a series 12V bulb (NOT 120V, unless they really wanted a trickle).

    Anyhow, high-wattage 12V bulbs aren't typically $1, and I figured out a workable solution with resistors and some less-extreme numbers.

    But, if you're in a jam and only have 120VAC, a diode, and a 150W lightbulb, ~1A charge-current ain't bad. Hmm, maybe I shouldn't return this bulb.

    Am curious about halogens, but that'll wait.

    Also curious about the I-V curves when heat isn't a factor... e.g. a really short pulse... hmmm...

    ...

    Actually, quite curious. A filter, laid-out like an R/C or R/L circuit... Short pulses would go through, until heated. Kinda like a charging capacitor..........

    oh snap, what's this a voltage-controlled attenuator?

    ...

    Search-fu is failing me... Seems there should be a circuit-model for these things, instead...

    Read more »

  • Coding! Coding again!

    esot.eric11/14/2018 at 07:32 2 comments

    Had every intention of launching right back into those code-changes/experiments today... Instead, the first few hours spent making my hokey 12V/5V wiring less delicate. Here's a tip: drill + zipties. 

    Also had a revelation... See, that 5V power supply was intended to drive the 'antPC' as well as peripherals (e.g. my old hard disk)... thus, all those high-power USB ports. And somewhere in there I had it in mind to use those ports to power my project[s] as well. Brilliant!

    But reality set in... I don't really have any high-current USB cables to cut for power. Oh, those dollar-store cables claim to handle 2.1A, but have you seen how thin they are? It's prb 4V by the time it gets to the other end. Fine for charging a 3.7V battery, but probably not for powering a 5V floppy drive's motors.

    So, then I dug around for long/thicker two-lead wires to wire right in to my 5V supply... and at the end of that I'd splice the 3.5in floppy power connector. Kinda hokey to have a special cable coming out of my PC for this particular project... But just as I started to cut the cord off a wallwart, I saw the most obvious answer.

    A friggin' power-cable from an old ATX power-supply... yahknow, yellow, red, two blacks, several connectors for both 3.5in and 5.25in drive-bays. Yahknow, kinda like one might find attached to the power-supply inside their computer, and might use to power things connected to their computer, like... a floppy drive. So, now, the antPC has power for peripherals... like PCs do. And it's plenty long enough.

    I can't tell yah just how much fight it took not to wire up that yellow wire, too. "I don't need it right now!" and "It'd be *easy* to do if I ever do." But, more importantly, I suppose, is that it'd be [relatively] unregulated, from a car circuit... 11.75V - 12.6V, when not charging... Those numbers aren't too bad, pretty sure I've seen the likes coming from ATX supplies... but 14.2 into a hard-disk with no backup, that's a little nerve-wracking. Better not connected, lest I forget.

    Did I mention that this seemingly simple task of stabilizing my power situation wound up taking hours? Yeah, several paragraphs, here, just recalling.

    ...

    And, one of the main reasons I undertook this 12V->5V endeavor several days ago, now, cropped up today... The [house] battery dropped too low for the inverter. My PC woulda suffered a power-outage, right in the midst of coding... but the 5V supply hung in there with plenty of time for a proper shutdown. YEAH!

    ...

    And, yeah, I got a few hours' experimentation/coding in.

    First experiment: remove varying data. Record the same value in every nibble on the track. An easy compromise from recoding to handle e.g. 2-value "nibbles", as described earlier, is to just record the value 0x0 or 0xf. DUH. and 4-value is just as easy, and so-forth.

    So, writing all 16 values, one on each track, runs several experiments at once.

    And... an interesting result: Silence and constant-brightness on the LED, as the track spins throughout the majority of each rotation... on every track... suggesting, possibly, the repeated values are being read the same. As expected. Possible.

    However, equally-informative, maybe, is that the brightness of the LED changes seemingly randomly (and a slight popping-sound) once with each rotation. Plausibly right around the Index pulse.

    Why?

    Well, writing of PWM-nibbles is delayed until after the index pulse... and stopped as soon as it's detected. So, there's a brief space on every rotation, on every track, where there's random garbage from long ago. This garbage is unlikely to look much like a properly-formatted PWM-nibble... OTOH, it might slip through my limited detection-scheme. So, maybe a random value comes through there...

    BUT, the proper nibbles are written everywhere else on the track, the same value. So, a slight blip near the index may be expected, but as soon as the proper nibbles are detected/read, the LED should show the...

    Read more »

  • Reinventing my reinvented wheel

    esot.eric11/13/2018 at 06:39 0 comments

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

    Read more »

View all 34 project logs

Enjoy this project?

Share

Discussions

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

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

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