Total coincidence -- I recently have been recovering games from my old TI-99/4A cassettes, also using an oscilloscope (the same model in fact; for no particularly good reason beyond it was the most convenient way to record off the only tape player I still own), Audacity, and two open-source tools to recover such data [2] and [3].
[1] http://www.unige.ch/medecine/nouspikel/ti99/cassette.htm
The common IBM PC and related formats use "double density" MFM: https://en.wikipedia.org/wiki/Modified_frequency_modulation
[edit] it actually IS mfm after all https://wiki.amigaos.net/wiki/Amiga_Floppy_Boot_Process_and_...
(Note that both of these also decode the TI's frame format; but it should be easy to pull out the core waveform decoder of either.)
It could only be Rigol or Siglent. Fascinating though. I know how slow floppies are, but I wouldn't have imagined an oscilloscope to have the necessary resolution.
In my case, the data was coming from cassette tapes, so the oscilloscope was absolutely overkill in terms of raw bandwidth by 3 orders of magnitude. However I was operating at its memory limit of 14 MSa (megasamples)... running at a sampling rate of 20 kSa/s, I had barely enough memory to grab the full 10 minutes of each tape side.
Its vertical resolution (8 bits) I was a little worried about, but the dynamic range of Differential Manchester/FM is so low it turned out to be a nonissue. Certainly the quantization noise is comparable to the noise floor of the basic-quality cassettes that my data was on.
Unlike HDDs, floppy drive heads do actually rub on the surface of the media in normal operation. This is notable because repeated "scrubbing" in an attempt to statistically recover data[1] can make things much worse, especially if the media surface (or worse, the head) is already damaged.
The attempt that bore some fruit was to instead locate the start of the sector data, and continually look at the next 8us of the analog stream. If the voltage appears to generally drift in one direction, then it's a "0" bit, or if the voltage peaks one way and then the other, it's a "1" bit.
More distinctly: if the signal difference between two samples 8us apart is approximately the same, it's a 1; if there's a large difference ("large" being something suitable and AGC-ish like a running average or similar), it's a 0.
[1] For optical media this is not a big concern, and I once wrote some code to recover degraded CD/DVD(+/-R) sectors by disabling the ECC of the drive and reading the raw data many times; it was surprisingly effective and interesting to graph the results as they were being obtained in realtime and see the bits literally rising out of the noise.
How did you do this? Is there some SCSI/ATAPI command for this?
(Contrary to some of the other comments in this thread, the drive was actually an LG.)
That should be able to read disks where the disk surface has stretched or warped, and the tracks are no longer perfectly circular.
I think there's also a reasonable chance such a method could also be used to recover data on a disc that has been overwritten.
For example there's this project that reads stranger formats http://cowlark.com/fluxengine/
https://en.wikipedia.org/wiki/Floppy_disk#/media/File:Visual...
A more-clever technique would write two sectors in a row with the same sector number but different data in each. The program loader would rapidly demand that sector twice, getting different data as the disk passed under the read head. A copy program, however, would only copy each sector once and be missing the data from the sector with the duplicate number.
This is also done in some optical disc copy protections, although the identically numbered sectors are far apart, causing seeks from the end to return different data than seeks from the beginning of the media.
Hey @dang, this account has made many good comments since then.
Looks to me like this is just FSK (https://en.wikipedia.org/wiki/Frequency-shift_keying), and if so that's great because it means you can use techniques more sophisticated than the ones in that post, which in turn means that you have a chance to go after more 'unreadable' discs.
Here's some references: https://www.rfcafe.com/references/articles/wj-tech-notes/fsk...
http://edge.rit.edu/content/P09141/public/FSK.pdf
There's lots of matlab code floating around out there, if you're willing to try gnuradio that'll work (for example: https://nccgroup.github.io/RFTM/fsk_receiver.html), and this looks promising: http://www.whence.com/minimodem/
ETA: Audacity might be able to do it too : https://www.youtube.com/watch?v=tKNNnbgoGdI
https://colab.research.google.com/drive/1Zvb6bQfC3thc5-39exp...
It took me as just a little odd to see "floppy disc" even if it's technically correct.
http://www.computinghistory.org.uk/det/21293/Diagnostics-Dis...
Not sure if it's a UK thing or a 1980s thing.
I think it's both, in the UK at least.
The Beeb in school in the 80s had a 5¼-inch floppy disc drive. The BBC Domesday project, 84-86, was on Lazer Disc. But as Compact Discs took flight in the domestic market we'd moved to 3½-inch floppy disks; which by the 90s were labelled "diskette" IIRC and so were called disks. Then hard drives were called hard disk drives I think because they came from the global/USA market, so the only "discs" that remained in common use were optical discs, and the split - for me at least - was kinda-retconned in that optical discs were always 'discs' and magnetic were always 'disks'.
The early UK made hard disk drives were [sometimes?] called "disc drives", http://www.computinghistory.org.uk/det/22567/%20Acorn%20BBC%... this one from Cumana, Guildford, UK, http://www.computinghistory.org.uk/det/36026/Cumana%205.25-i... says "disk drive" though, and I'm shocked ;o) ...
You reminded me of the https://kol.coldfront.net/thekolwiki/index.php/Boock_of_darc... :D
Meanwhile a "disc" is any flat circular object.
So floppy disk, hard disk, but compact disc, is correct.
The only medium I know of that doesn't obey this rule is the Sony MiniDisc. MDs are definitely diskettes, and so should in theory be spelled MiniDisk. But presumably that's for trademark reasons.
Doubtful there’s any treasures to be found here, but reading this article is giving me some inspiration to spend some time on this project again.
Another great restoration in all its technical glory is one of the flight computers from Apollo[0]
Certainly I'd like to make contact with other people who are working in this area and compare notes... if anyone doing so is reading this, please do make contact. I'm on Twitter under the same username, Chris is @scarybeasts.
If you prefer email you can stick "@gmail.com" at the end of my HN username to get that :)
At the moment I'm working on cleaning up the remains of the DiscFerret project, and turning the project website into a general retrocomputing data recovery wiki.
Good thing I bought it cheap from China.
So, the operating system could verify the write by reading it back, but I don't think the BBC Micro disc ROMs typically did that for file writes -- only for formats.
.jpg){kind=link}