Floppy-bird

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.

He did it!

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

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

/30/480=85.75bits/scanline

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?

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

https://surfncircuits.com/2020/11/27/implementing-a-single-edge-nibble-transmission-sent-protocol-in-python-for-the-raspberry-pi-zero/

2021-09-21:

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

https://hackaday.com/2021/09/16/tesla-door-handle-improvements/

->

https://en.m.wikipedia.org/wiki/SENT_(protocol)

->

https://www.idt.com/us/en/document/whp/tutorial-digital-sent-interface-zssc416xzssc417x#:~:text=The%20basic%20unit%20of%20time%20for%20SENT%20is,starts%20a%20message%20frame%20and%20provides%20a%20method.

...

<sigh>.

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.

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.

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!]

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.

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

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)

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!