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

[Alexander Jacocks]

I'm watching the development of the AppleSauce controller, and it's
accompanying software, very closely. I've had a chance to use the device,
at KansasFest, and it's a very well-engineered device. Since they have
expanded the imaging capabilities beyond just the Apple II, it's of much
more interest to me.

- Alex

On Fri, May 8, 2020 at 6:45 PM Herb Johnson via vcf-midatlantic <
vcf-midatlantic at lists.vcfed.org> wrote:

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