[vcf-midatlantic] How To Geek article on floppy data recovery

[Herb Johnson]

So, Gordon S. writes, something like this. He buys-in, that these 
floppy-recover solutions, are made from currently available hardware, 
but that hardware goes away over time. So, he says, why not implement on 
widely available and well-sourced hardware? The challenge as he put it is:

"The only real irritant, then, becomes working out how to cheaply do 
whatever it is these other projects are using FPGAs for. Those are the 
parts that get updated whenever someone works out a better technique, 
but... as a general rule, the  interface to whatever vintage hardware is 
more or less invariant, correct? That would mean the alterable functions 
can be carried out in software rather than in (redefinable) hardware. 
Flash updates are still flash updates, regardless of whether they 
contain computer programs or FPGA configuration files."

"Can anyone poke holes in this? - Gordon S".

Well, I reject the limitation "cheaply". That constrains any modern 
solutions to the hell of rapid obsolescence and proprietary solutions. 
That's the current strategy. I'm being blunt but brief. At $10, $20 
single-board single-chip solutions, how does any hobbyist outdesign 
*that* with more persistent hardware?

The vintage hardware interface, is either a floppy drive for data 
recovery; or a floppy drive controller, for diskette emulators (not 
discussed but the complimentary device). Well, po-TAE-toe, po-TAUGHT-oe, 
to a first order. That's not the hard part.

On FPGAs, and the hard part. Turns out the support page for the 
Fluxengine, is pretty informative about this and other arguments for 
alternative technologies. After five years, that's already been defended 
(but I only read the gloss).

The defense is, it comes down to the design practice, of massive 
oversampling of floppy data streams, to extract arbitrary-rates of 
binary data relatively fast. Go to the site for details. So: one ether 
borrows cheep ARM-class devices that do that, or cheep FPLA devices 
which do that, or both. Because of that "cheap" constraint. Shrug.

In what used to be the real world, floppy disk controllers were 
dedicated microprocessors with fast bit-serial/parallel hardware. Read 
the early floppy controller FDC chip data sheets about that. They ran at 
defined data rates - so write hardware was easier. Reading hardware 
involved some skew, so one needed some tricks to sync-sample the read 
data. We call that data, single/double density, FM/MFM. Or the Apple 
mind-trick of the Apple II (later Mac) "Woz machine", a programmed-logic 
device (!) to perform 3-of-5 encoding and decoding. Or, some custom 
hardware and software, on other computers of vintage.

At one time, ALL floppy controllers were custom logic. (Search 
retrotechnology.com ) Now, in some sense, the custom logic is in the 
FPGA. This might make a case for preserving vintage computers (he he ...).

To replace all that, the cheat is to sample like hell and let 
post-1990's computers sort out the results in software. Fair enough.

I appreciate Gordon's point, that functionality in modern devices is a 
matter of programming, and reprogramming. That's fine, for those who 
enjoy modern embedded programming. But when the hardware to be 
programmed changes "too much"; the old software becomes obsolete. 
Yesterday's FPLAs can't be programmed with today's FPLA tools. The codes 
are changed too. The binaries are useless, even proprietary. That was my 
point!

Subtle comment by Gordon: "We already know what stays around, or at 
least remains well-documented and well-supported." Trick question. The 
trick answer #1 is "that's the same thing". Answer #2 is "well, stuff 
persists until it breaks; if you can't fix it you replace it". Sort of 
the short version of the argument.

Now, the software to RUN the platform around the FPLA, could in 
principle be standardized. For big-enough embedded systems, that's fine, 
they are application-specific not implementation-specific (kinda). But 
this is just a *floppy controller*. There *is no application*. Nobody is 
running MS-DOS or Linux on these puppies. They are driven-by something, 
the something steers it around, and that's all.

And by the way? The 1990's solution - the Catweasel, an ISA or PCI 
bit-sampling controller on PC's? Last I checked, there were five-six 
"installation solutions" for running that puppy. Surprisingly, each 
developer came up with their own software to drive it. Go figure.

I don't know how much that happens, with 21st century $20 
microcontroller solutions; the Arduino platform is pretty established; 
the RaspPi, somewhat the same. Then each other device-family, has their 
manufacturer's development engine software (to keep you from using 
another product, he he). I made that point before.

So: walk through this with me. What floppy control hardware is pretty 
much standardized, available, and stable; year after year and even into 
decades? and what software to support what software to drive it, has 
those qualities? Answer: XT/AT/386 class PC's and MS-DOS. And that's why 
solutions like "Imagedsk" / MS-DOS / ISA floppy controllers / IMG files 
just keep on workin'.

But they don't work for 68K Mac disk formats, Apple II disk formats, 
etc. etc. That's why bit-sampling general solutions emerged in the 
1990's, from Compaticard to Catweasel. And you know, maybe I'll think of 
a 1985 solution to the problem for those reasons. But it's harder to 
design PCI cards; many people don't have computers with PCI slots; USB 
is the "bus" of choice; and there's those dammed $10, $20, $30 
stick-puters. They are the black-holes of design-your-own-devices.

But the question of the day, was about a $10 solution. It's an amazing 
bit of application, that FluxEngine; as is/was the GreaseWeasel. But 
it's like other $10 embedded solutions, with all the faults I mentioned 
and alternatives Gordon suggests. One can work around these, because in 
the end, nobody is gonna die because a $10 embedded stick coughs and 
sputters, or can't be found. There's no mission-critical task in play 
that matters. They will come and go, as do supporters of some 
application like read-a-floppy.

Sorry for the long lecture, I got a real question and it took time to 
answer it. Hope this did that.

regards, Herb Johnson

-- 
Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT retrotechnology DOT info