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

[gsteemso]

Hi all,

>> On May 8, 2020, at 2:45 PM, Herb Johnson <hjohnson at retrotechnology.info> 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?

Yep, pretty much.

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

*cough* Uh. I must apologize -- I was a bit sloppy in my wording, and should have written "inexpensive" there. By "cheap" I only meant "less expensive than buying, restoring, configuring, and operating an obsolete peecee for the same purpose". I quite agree that trying to do anything worthwhile with inadequate materials is a fool's errand.

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

I was fairly certain that would be the case, but it never hurts to check my assumptions. As you point out, if you go back a few years floppy controllers were not monolithic -- which (I infer) meant they did not necessarily present a wholly consistent interface to whatever host system was involved. A bit further back than that, there wasn't even a standard interface to the _drive_. How flexible _does_ a floppy controller have to be for maximal usefulness?

> On FPGAs, and the hard part. [...] it comes down to the design practice, of massive 
> oversampling of floppy data streams, to extract arbitrary-rates of 
> binary data relatively fast. [...] 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.
> 
> [...] the cheat is to sample like hell and let 
> post-1990's computers sort out the results in software. Fair enough.

True. This all looks simpler in my eyes than I've been getting the impression is assumed, though. If the goal can truly be reduced, in hardware terms at least, to recording a high-resolution image of the disk's magnetic state -- why in the heck is that considered so challenging? Please check my reasoning here...

I figure that current incarnations of 6502 and z80 CPUs are more than an order of magnitude faster than the first ones were. A parallel I/O chip to bit-bang the stepper motor controls is a _commodity_ item, as are ADCs to digitize the signal from the drive head. The rest is just dumping the digitized data into a buffer, and we all know that widely-used disk-image formats can remain actively supported for decades. Put a dirt-simple, old-school serial port on the wretched thing to control it -- they've been introducing "better" replacements for 40 years, and we still have RS232 et al because they were ubiquitous -- and voila. What am I overlooking, here?

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

This! This right here. Why is _every_ solution to this stuff I've seen done with some microcontroller? In a case like this, simpler is, well, _simpler_. We have, and maintain, and in many cases can _build_ hardware that works exactly the same as it might have 40 years ago, at four or five orders of magnitude lower cost.

Is there really any hardware tinkerer on this mailing list who would resist designing something around (say) a 65C02, on the basis that there'd be no support for it in 5 years? Try and say _that_ about the FPGA of the week.

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

And mine! This sort of conversation has been called "being in violent agreement" by a friend of mine. *grin*

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

That thing sounded great in principle... but getting one _and_ a host system which could actually run it was far beyond my means at the time, and the entire project was long-out-of-production unobtainium by the time that changed for me. The whole experience left a very foul taste in my mouth.

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

Yep. But if you never used one, never had a reason to get used to them, and really don't enjoy fighting with one to keep it operational, I personally feel that an imaging station built around one does not enhance the fun of retrocomputing. YMMV.

> But they don't work for 68K Mac disk formats, Apple II disk formats, 
> etc. etc.

Well, mostly. There are a handful of really clever programs that basically take over an older pc's floppy controller at the lowest possible level and do unnatural things to it, with impressive results; I vaguely recall using one called "Omniflop", or something to that effect, that was able to read & write Commodore 1581 floppies and -- IIRC -- read but not write an 800K Mac floppy. If you had a compatible FDC the thing could do a surprising amount -- though, as you point out, not everything.

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


It did indeed! Like all good explanations, it got me to think through just what my assumptions are -- and, potentially, what assumptions I ought to make instead.

Regards,
Gordon S.