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

Herb Johnson hjohnson at retrotechnology.info
Sun May 10 14:21:47 EDT 2020

> Jack Rubin > Sat May 9 09:41:14 EDT 2020
> Hard to reply directly to your post since I only get the vcf digest, but a couple of points re new modes of disc (I'm an HP fan) imaging.
> 1) The flavor-of-the-day MCU or whatever isn't as important as maintaining accessible disk images and metadata. Flux level transcriptions weren't really practical when Dave Dunfield was building his ImageDisk system, so we should be thankful for all the extra CPU cycles available to us today, especially in a $15 package.
> 2) The approach is a little different but the philosophy is the same - for ImageDisk stuff, I still have a Dell 486 with all the right stuff, including an FDADAP and a Thinker Toys 8" floppy, but I also have a couple virtual machines with the proper toolchains installed to control a few Arduinos and PSoCs for the new stuff that demands a full software ecosystem beyond the hardware. More important, today's cutting edge developers can still read (and write?) .imd files.
> I was thinking about this last night as I was installing and configuring all the stuff necessary to start working on my first Verilog project. It took me a lot longer to get the point where I could blink a light on the demo board than it would have to reconfigure a CP/M bios for a new serial card and sysgen a new system.
> Be well and stay safe,
> Jack

Always good to hear from Jack Rubin, an old friend. I'm going to reply 
back in the previous thread, and include Jacks' post there. And I've not 
decided I'm being a curmudgeon, yet. My responses focus on the tech, not 
my attitudes. Unless of course, being technical is old-school now. ;)

Again, this argument takes awhile. For the impatient: Jack has not 
convinced me of the merits of short-term disk-imaging solutions. I'm 
focused on the delivery hardware; Jack on the imaged disk results. In 
effect, he's conceding to the modern reality of what I call "popsicle 
stick computers". But I think he misses something, in not focusing on 
the problem of non-persistent tech, and ignores problems with 
flux-imaged file formats. I end by pointing to the irony that interest 
in keeping old stuff around is called "curmudgeon" in a vintage 
computing discussion.


Jack's point 1 says, accessible disk images and metadata matter. That is 
correct. But that's not all that matters. Of course, if we are voting on 
what matters: then a million for-free emulator users, outnumber the 
hundreds who create the disc images. But whose role is critical?

The problem I point at, is disk imaging hardware and software which 
becomes obsolete. The fact it's $15 technology makes it more LIKELY to 
become obsolete. And when the hardware is obsolete, you can't add more 
imaged discs, and at some point the already-imaged content become less 
accessible as the software falls out of favor, off-line. And developers 
of new-tech, often enough start from scratch.

This consideration has occurred with a more expensive tech - the 
Catweasel. Only persons who bought those decades ago, can exercise the 
hardware; the software has persisted but many people are unfamiliar with 
the device or its flux image formats. That's what obsolete looks like.

An aside: Dunfield didn't need to flux-image diskettes, because almost 
all the 1980's and 70's diskettes in question, were accessible with many 
available ISA based PC-compatible floppy controllers. Dunfield's genius, 
was to identify appropriate floppy controllers!(Some stuff got left 
behind: Intel Multibus M2FM format disks took decades to be recovered 
for reuse. That history I know.)

  And: he came up with means to native floppy controllers which were 
incompatible. Namely, one injects into the native machine a downloader, 
which can then download a native program to format and fill a 
diskette-image - COLD. And: Dave stored his .IMG images as BYTE data in 
sector/track order, in a specific format.

The .IMD format became a defacto emulated-disk format for many emulators 
of 1970's and 80's computers in the PC-compatible enviroment (of the 
1990's forward). Those emulators would have gone nuts, decoding fluxes.
As Jack points out in his point 2, many developers today still support 
.IMD format. It's hard to avoid: it's essentially as-recorded 
byte/sector data.

I dwell on those points, because all those features of Dunfield's work, 
have been reinvented by other people - or forgotten by other people - as 
they reinvent disk imaging technology.

Jack's point 2. He says "the philosophy is the same" between using a 
1990's PC and IMAGEDSK and physical drives, versus use of a modern 
desktop computer with "the proper toolchains" and "software ecosystems" 
for arduinos and PSoCs.

Well, that's *almost* the problem I call out. What Jack neglects to 
mention explicitly, is that for *each* Arduino or programmable system on 
a chip, one needs *another ecosystem*. My point is: if one wants to 
maintain or recreate an "old" (five years ago) Arduino or PSOC, one has 
to have or find that old ecosystem, and find that old piece of hardware.

Jack appears to be saying, one doesn't have to "maintain". One ignores 
obsolescence, simply keeps the data, and moves along to the next "flavor 
of the day MCU". He doesn't say how flavor A's flux-images are 
reinterpreted by flavor B's flux-imager device. Or how 
computer-emulators might be obliged to support several flux-imaged 
formats. In fact he leans on the obvious choice for emulators, 
byte-correct  formats including .IMG. I"ve all but explained why that is.

I'm aware, Jack, these popsicle-stick computers don't and can't stay 
around long. They aren't built for that purpose. The world most of those 
MCUs are produced for, is a short-life world. Think cell phones.

But: the Arduino world, is a meta-environment created and supported to 
solve that problem. It EXACTLY allows Arduino-class devices to come and 
go: one keeps the Arduino environment but changes the libraries to match 
the popsicle flavor desired AND available. There's consequences that are 
off-topic to discuss, but Arduino has persisted as a working solution to 
obsolescence and transient technology.

But for this topic: not all Arduinos or MCUs or PSOCs have sufficient 
hardware to perform rapid bit sampling of 100K-bit data streams. So, 
some of the "flavored" disc-imaging hardware solutions, are not in the 
Arduino universe. That makes hardware obsolescence a *worse* and 
more-likely problem.

To Jack's point as I see it. To developers of these  of these 
flux-sampling disc-samplers and producer devices, they just hop to 
current products and platforms for them. No problem - of course they 
self select, we only pay attention to the successful results.

To the "customers", all my considerations are techno-babble. They aren't 
developing anything. They buy what is available. The disc libraries are 
there, for free. They are consumers and outnumber the producers, if it 
comes down to a popularity contest.

In between, is the tough part: the people who image found diskettes. 
They don't likely have technical skills, much less PSOC developer 
skills. They will buy and run, whatever disk-imaging hardware they can 
get today; or pass their discs along to whomever has such stuff. Or the 
disks are lost. And, contrary to prior discussion, disks are still 
found, and still lost.

Now: there's people who want to restore and run the vintage hardware. 
Like me, like many that's part of the audience in this email list. Are 
they all required to be PSOC developers? No. Are they all required to be 
1980's 90's digital engineers? No. They make choices about what old-tech 
to have and what new-tech to have.

But they choose between a $500 CP/M machine (or Amiga, or Mac) and a 
zero-cost emulator on their laptop - who wins that? And so they choose 
USB devices for $10, $20, over some clunky floppy drive that needs $100 
of additional hardware for either domain. Again - who wins the vote for 
modern over vintage, even among vintage-computing enthusiasts?

In closing: It's funny to use the word "curmudgeon", in an email list 
exclusive to those interested in 1980's and 90's (and earlier, maybe 
later) computers. Because, it references age, and the subject is 
old-stuff. But the actual reference, is to old *people*, and the 
consequences of having accumulated knowledge and experience, versus 
(pardon me) a larger world where those are lost in normal practice.

My regards to Jack and all,
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

More information about the vcf-midatlantic mailing list