[vcf-midatlantic] How To Geek article on floppy data recovery
David Gesswein
djg at pdp8online.com
Mon May 11 21:50:52 EDT 2020
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.
More information about the vcf-midatlantic
mailing list