The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
As long as your machine can see it, it works well. Just don't lose it
I went through some serious hoop jumping trying to get an enclosure for my SSD, a Samsung SM961, PCIe 3.0x4. It's a bit faster than your generic SSDs, but it has some unique connector requirements and enclosures are pricey.
I have a friend who has gone to all virtual machines, and he just carries around a couple of USB 3.0 enclosures. Apparently the system works well for him.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
This is not a programming problem, even though it is a software thing - so kick me in the right direction, if the question doesn't belong here...
I've got quite a few boxes of old floppies that I want to go throught before throwing them away. I've got a USB floppy station.
In the old days when floppies were the standard, lots of floppy manufacturers sold "pre formatted" floppies ready to use. But they didn't write the format code (360K, 720K, 1.44M...) in the boot sector. Don't ask me why - it is true that Good Old DOS (GOD) didn't require it: If reading according to one format failed, another format was tried, and another, until reading succeeded. 16-bit Windows (i.e. up until W98) followed suit. With Win32, MS declared that "Enough is enough!". In XP and later versions, a floppy without a proper format code is considered "Not formatted".
I could fire up that old W98 wreck down in the basement to spin through all those old floppies. The machine is really old, so moving the rescued files over to my current machine today raises another set of problems. I'd rather find another solution.
So, my request is: Can anyone point me to some software letting a Win7 or Win10 machine read a floppy from a USB floppy drive, even when the floppy disk does not have a format code written into the boot sector as it should have?
95/98 might be overkill, if it's just to copy files from a floppy to another location (say, a virtual hard drive, formatted as FAT). I've had DOS install just fine on Hyper-V, but 95/98 have always failed for me (with Hyper-V, that is - thought I remember using it with VMware).
The first thing Windows says is somehting like "This disk is not formattet - do you want to format it?" I have to get beyond that point to copy the files on the floppy to another location. And once I get beyond that, the problem is solved.
As long as any current Windows floppy driver is involved, I can't get access to the files on the floppy.
So the host OS gets a crack at it before the VM? That's kinda messed up.
I've kept around old machines, but not that old. I have a USB floppy drive somewhere, and I know I have DOS install disks (or at least a bootable DOS disk), so maybe I wouldn't be completely stuck if I needed to do that. Although I have to seriously wonder if those floppies still work.
I haven't actually checked out this combination. It depends on the virtualization. Usually, VMs do not have their own drivers for every single hardware device that is out there; it makes use of the host's device drivers, at a low level. Different VM technologies vary in how low level - drivers are structured in multiple layers. The term "driver" is a most ambiguous term.
If the VM software goes all the way down to the drivers for every piece of hardware, without any support from the host system, it really isn't a virtualization layer but an OS core that provides multiple isolated API environments, possibly of different types.
Where does the "OS provided device driver" end and the "host OS" begin? That is also a very ambiguous issue. The VM may use the host OS to provide control over the disk as cylinders and tracks, but manage the sector format itself. Or the OS may provide the disk as an unstructured stream of bytes. Or one of several in-between levels.
As the floppy disk format really describes the disk at the cylinder/track level, its interpretation belongs in the very low driver layers. I woudn't expect a VM anno 2019 to implement drivers for the Shugart 34-pin floppy interface - legacy demands on Windows are probably still strong enough that they keep it in there. What you suggest is that the VM implements the physical layer driver (if it is prepared to do that for arbitrary USB floppy formats, I would expect it to be available for a Shugart interface as well), but not take the responsibility for track and sectors. Or at least allow me to take control over stepper motor and disk rotation ... in a "virtual machine". To me, that isn't much of a virtualization
You may be right, but I doubt it. I would think that the majority of VM technologies that can handle floppies make use of host provided drivers at the bottom layers. If those drivers can't handle the sectors and tracks because there is no information available, I would expect the VM to be lost as well.
That was my concern too, the host would say "ahh, this is a disk drive, so these are the parameters, here you go VM..."
OTOH I've had VM's talk to devices that the host didn't understand (custom sensors), perhaps disabling the USB-Floppy driver in the host might let it pass through as an "unknown device,"
... but then my next fear would be without custom drivers (as I had in my case) the win 95/98 probably may not know what an "unknown-?USB?-thing" is either.
But if no luck elsewhere I'd try VirtualBox, I've found it's generally best at passing through devices. It's free apart from a bit of you time invested to download and install/setup.
That's what I did. That's what doesn't work. Because Window reads the boot sector and finds no valid format code written to the disk. It then does NOT try all the different alternatives, the way DOS and Win16 dit, but bluntly rejects the entire floppy. No matter which floppy drive you buy, it won't simulate a format code that isn't on the disk.
Maybe because you back in the old days formatted all the floppies yourself. Then a proper format code was written to the disk.
In the (very) old days, floppies were totally unformatted when you bought them, you had to format them yourself. When you bought yourself a new 10-pack and wanted to prepare them all for use, you'd spend a significant fraction of the afternoon waiting for the job to complete. (And remember: In the DOS days, you couldn't use your PC for anything else while waiting.)
As a service to the customers, the makers of floppy disks started selling "pre-formatted" floppies. Unfortunately, some of the largest brands failed to write a proper format code. I don't know if there might have been any logical reason not to, but that's how it was. At several occasions, I was offered batches of unused, but obsoleted software floppies: When a new software version came out, it was cheapier to ditch or give away the old version, than it would be replacing the labels and rewriting the disks. These mass produced floppies was similar, in that they lacked the format code.
My guess is that floppy writing "robots" for making ten thousand identical copies (whether blank or filled with software) per batch was such a small market that there only was one, maybe a couple, models in the market. If these machines were fed the files only, and did't themselves write the format code, it could explain why such a large fraction of pre-formatted / pre-written floppies had this defect.
Most BIOSes dropped support for 5.25" floppies a decade before they dropped support for 3.5". And if you're trying to do anything with 5.25" disks, you'll need that old BIOS. I had go to several layers deep in my pile of motherboards before I found one that worked. Good luck with that.
Last Visit: 18-Jul-19 1:26 Last Update: 18-Jul-19 1:26