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