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

[Tony Bogan]

John has continued to push the software and hardware to its limits. He hopes to eventually get a windows client as well. It can currently do Flux images (a2r) of Apple II 5.25”, 3.5”, macintosh 3.5” 800k and 1.44mb disks. 

We have one for VCF and I have a couple including one of the prototype units since I was an alpha and beta tester.

I’m not sure if the VCF one ever had the upgrade done, I’ll have to check it. Eric Rangell set it up originally.

I know it should be able to do some other formats but I don’t recall if that’s been built into the software yet. I haven’t had an imaging station set up for awhile though I continue to follow his updates.

Tony

Sent from my iPhone

> On May 9, 2020, at 6:12 PM, Alexander Jacocks via vcf-midatlantic <vcf-midatlantic at lists.vcfed.org> wrote:
> 
> 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
>>