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

[David Gesswein]

Continuing the long reply tradition:

I wanted to join this discussion earlier but had another distraction.

This is my take on this as actual maker of a flux imager except for MFM
hard drives and a user of floppy imager.

I don't see the issue as being the inexpensive hardware I see that as an 
advantage.
I've seen a number of people say they can't justify getting my reader because
its too expensive to for reading one drive. I suspect some people
aren't going to shell out 99 euro for the Kryoflux to image some floppies 
but might get a $10-$20 board. The Kryoflux is the long term supported 
imager (around at least 10 years). It has some licensing issues that 
encouraged people to make alternatives.

The blue pill problem you discussed is a separate issue. My time is
too important to save a couple $ if I'm going to waste time on poor
hardware. Simple to use would be nice but its a lot of effort for the
creator and the real world variability makes it hard. I'm sure users of
my tool mutter what was I thinking at times. I liked the FluxEngine
simplicity of only needing a connector soldered to it. No custom board
needed.

I got a KryoFlux since I had a bunch of M2FM disks to read and had 8"
drives but no Intel MDS to image them. Still processing them but they
will get to Bitsavers and anywhere else that wants them.

I see the real issue as that the projects don't cooperate. Each one implements
their own set of decoding tools and image formats with limited ability to 
convert between image formats. I got the Kryoflux because I found a decoder
for it for Intel M2FM. It had some issues and I fixed some then found out that
their was another project that I didn't know about that had a decoder with
the issues I spend time fixing already fixed. I have only looked at
them a little but it looks like the Fluxengine and Greaseweasel are doing
the same separate development with limited ability to capture flux files
on one and use the decoder from the other if it has the format you need.

I think most of the value is in the decoding code. If it was properly isolated
from the hardware specifics then when the one inexpensive board goes away
and the next person creates an imager around the next board it wouldn't matter.
I've spend a lot of time adding support for the 50+ disk formats my tool 
can deal with. And that's only the low level disk format. I'm not touching 
the file system formats. So far I'm the only tool that reads MFM hard drives
so no ability to cooperate with others. I did make some attempt to allow the
format to be useful for other boards such as putting the sample rate in the
header of the flux transition file and not just assuming the rate my board
uses. I will admit my decoder will just print an error if the file rate
isn't what I use but that could be fixed if needed.

I also image with real hardware when I have it and I distribute software
for the PDP-8 to allow people to image various media on the PDP-8. A selection
of tools allows people to pick the one that is best for them. Its only a 
problem when the accessories (decoders & file formats) are tied to the 
tool that you care if one particular tool is discontinued.