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