• Please review our updated Terms and Rules here

How can I connect a 5.25" floppy disk drive to a modern computer?

dag10

New Member
Joined
Jul 30, 2011
Messages
5
I need to write some 5.25" using a modern computer.

I think I'm going to buy this internal 5.25" floppy drive:



Here's an idea I had: I buy an old ISA Floppy Drive Controller Card, and a floppy drive connector cable, and then somehow hook that hard up to my computer. Would one of these things work?

I don't know much about these things, so all help is appreciated. Thanks!
 
I connected a 5 1/4" drive to the most modern computer that I could find that still had a 3 1/2" floppy drive, connected to the motherboard with a normal old-style 34-pin connector. Obviously I also needed a cable that would fit the drive. I don't remember where I got the cable from, or if there was one in the computer already.

The reason I wanted as new a computer as possible was because I wanted to network it (and I also installed Linux), just so that I could read old floppy images. Sounds like you've got your modern computer already, but does it have ISA slots then? And if it's old enough to have ISA slots I would think it also has a floppy interface already?

EDIT: Looked at that link - PCI to ISA adapter, eh? Don't know if that'll work. What about just looking around for a computer with a 3 1/2" floppy drive? I got it for free, it was to be dumped anyway.. actually I got another one later when the first developed a problem. Just had to find one that was new enough to have an Ethernet connection (or I could have scrounged around for an ethernet card too, but I didn't have to in the end)

-Tor
 
Oh, no my computer doesn't have ISA. I forgot to type that it's a super-modern motherboard (ASUS Rampage III Extreme). I was thinking maybe there'd be some sort of PCI-ISA adapter or something.
 
No PCI-ISA adapters exist, at least in fully functional form for these late chipsets.

So the scenario I predicted is coming to fruition.

Anyone interested in a legacy floppy-to-USB project?

There are also things like the Deviceside thing, but I don't know how much support there is for transparent floppy (to Windows) handling. My guess is that it requires their own drivers.

Note that the other thing gone is PATA support.
 
For Dag10's purposes and level of experience, I would support Tor's suggestion.

You should be able to get an old desktop PC box, say a Pentium 2 with on-board ethernet and 3 1/2" floppy drive, either free or anyway for much less money and trouble than finding and installing FDD support in a modern PC.

You might be lucky enough to find an AT-class machine old enough to have its own 5 1/4" Floppy, though these are getting scarcer. You seldom see those boxes on auction sites because shipping costs way exceed market value. If you get a very old PC without networking, it's still easier to find an ISA or PCI network card (depending what bus options are on the motherboard) than to put together a special-purpose adapter.

Try the "wanted to buy" and "wanted to sell" parts of this Forum and check out recycling places near you.

Older small form factor IBM and Compaq desktops are generally good quality and save workshop space. The oldest ones may still have the FDD cables with the edge-connector plugs that you will need for a 5 1/4" drive. That cable may be the hardest component to find sold separately.

If you already have a LAN, then you can set up such an old machine as your "adapter" by making it "share" the 5 1/4" drive on the network - using Windows Networking (or Samba if you are using Linux). After setting it up, you won't need a monitor or mouse on that box. Some older machines won't boot without a keyboard attached. Some give you a BIOS option to boot without a keyboard.

If you don't have a LAN, you can make the connection direct to your main PC with a null-modem Cat5 cable.

When you have found the solution that suits you, come back to this thread and tell us - it's helpful for later visitors.

Rick
 
Anyone interested in a legacy floppy-to-USB project?

The problem is not really the hardware, its the Software. Windows 7 simply does not support 360k or 1.2mb disks very well at all.

My experience in this matter agrees with Tor and RickNel. An older Windows 98SE is my machine of choice to read and write both 360kb and 1.2Mb disks (2 different drives), and I use my 486 if I need to do any 720kb disks.

My Windows 7 machine has a ASUS motherboard in it and even though it has a floppy connector and the BIOS says it will do 360kb or 1.2mb it really actually does not. It also only supports a single drive.
 
The problem is not really the hardware, its the Software. Windows 7 simply does not support 360k or 1.2mb disks very well at all.

Well, Microsoft has been screwing with the legacy floppy controller drivers since they came out. Sometime around Windows 2000, they split the (well-documented and beautifully written) floppy driver into two parts--a floppy controller interface and the logic to interface to floppy drives. Then, various features have been deprecated in Microsoft's style.

It's still possible to interface to the floppy controller in Windows 7, but I don't really see the point. Floppy support is gone in modern motherboards; the media is getting harder to find--and the drives themselves are getting pretty creaky. It'd be beating a dead horse.

I've got a couple of later motherboards that have support for only one floppy as well--in both cases, it's because of a SMSC "SuperIO" chip that lacks the signals for the second drive motor select and drive select. Two lousy pins on a 144-pin QFP. It's pretty clear what's been in the works.

Perhaps a cheap floppy emulator really is the solution. Get rid of the drives and media altogether.
 
I don't see why you need a floppy drive on a modern computer, will any of the software even run if you could read it? One of the cool things that happened when people started trading ISO's of CDROM images in a CDROM emulator you can load images into, doing the same with a floppy images would be cool (especially if you could do it on vintage gear).

I suggest people with a large media library just keep around a few older machines to read those old disks (same reason I have a ton of tape drives and optical drives in my collection).

One more thing, do the latest Linux builds still support legacy floppy drives and controllers?
 
Linux builds still support legacy floppies but won't automatically handle mounting for the user anymore. Well, that is the case for Centos 5.6. Creating the mount points is easy enough but the removal of the existing mount points was an undocumented change in an update. I expect that future versions of the Linux kernel will remove the floppy driver from the standard compilation.
 
As for USB, the Kryoflux can work as a USB-FD interface, at least for reading floppies. Write support is in beta test right now. Maybe there are other projects out there as well, but I'm only familiar with Kryoflux because that's the one I've got already.

-Tor
 
As for USB, the Kryoflux can work as a USB-FD interface, at least for reading floppies. Write support is in beta test right now. Maybe there are other projects out there as well, but I'm only familiar with Kryoflux because that's the one I've got already.

Ideally, any solution should embody generic FAT device support. Not a utility program, but fully integrated as a native NT, DOS or Linux device; that is, something you can run programs from as well as read and write on a sector basis. The standard USB 3.5" floppy is an example of such a device.
 
The problem with archiving old data formats is not, IMO, archiving the old data. I think there are some solutions out there now that are answering that challenge nicely. The kyroflux usb adapter is a good example. I just found out about that project and am interested in reading more about it. But I digress- I think the bigger issue is that the software being imaged (at least with games) is often time protected with intentional floppy disk problems. Whether it's messing around with the sector structures, or causing intentional disk read errors- even if you can properly read these things (where errors are at, etc), that doesn't help you much. You have to be able to properly EMULATE the system for the archived material to actually run.

So the direction I'm wondering is whether or not something like DOSBox could be adapted to support such low level floppy access modes through an emulated floppy interface, or an actual floppy interface. An emulated one would require coming up with an archiving format (IMG, etc) that properly supported various "illegal" floppy situations. A hardware approach would be a driver to something like the KyroFlux hardware that supported the required low level access controls. Running in something like DOSBox that is a completely emulated environment separates you from the low level access protections that the host OS (windows, linux, etc) may impose.

I ventured earlier tonight in some quick research on whether such a project was possible. Stumbled across KyroFlux, and then this forum thread. So I'm fairly new in knowing what's actively being pursued out there. If anyone would like to steer me in a direction that might already be solving the problem I'm discussing, I'd be all ears.

To be clear, a hardware-interface solution would only be good as long as the hardware (disk and drive) worked. Fine for now, but another 15 years, maybe not. A data image format that properly includes copy protection scheme characterization however, would be even better for long term data preservation and execution. DOSBox goes a LONG way for us today. Can it (or something else) be leveraged just a "little bit farther" to include copy protected media emulation???

cheers,
..dane
 
Could it be done? Sure, I suppose so--does DOSBox emulate things that run at exactly 4.77MHz? If not, there's a problem right there, as some schemes were timed with CPU loops. Many games booted without DOS.

The 765 isn't complex; an emulator could certainly be produced. Sharpen your pencil and get to work. Games aren't my thing, but I can tell you a lot about copy-protection schemes.
 
In my understanding, I believe dosbox does "execute" instructions based on number of cylces per second. I don't know they handle it in equating to processor speed, however. I believe it is more of an emulation of how many MIPS rather than an actual oscillator rate. So depending on how the timing structures are created (and which machine mode it's in), it may or may not be equivalent. I can look to find that out, however. Good question.

Someone else pointed out to me that Dosbox uses SDL (Simple DirectMedia Layer) for a lot of its low level access. But that's assuming we're trying to access actual hardware. Emulation is another matter. Being a hardware designer, I don't know that I'm qualified to attempt an emulation of the disk controller. I was originally hoping I could develop some hardware and team up with someone who could develop some software. then I found KryoFlux and at first glance it looks as if their hardware answers everyone's prayers. So that would just leave dosbox support for the IPF format or something such like that. Though what I'm reading is that KryoFlux won't generate IPF right off- which I can understand but is discouraging. I have a bunch of old 80's games that I'd like to archive and play without needing a physical drive everywhere I went (in a plane, in a train, with fox, in a box). But if I can't make the archive file from my personal floppy, then what? I'm trying to figure that out..

Let me figure out a bit more about what DOSBox is doing, and what's going on with KryoFlux. If there's any hope, I'll come back and ask you more about it. The fact that you know a lot about the protection schemes would be very valuable if I were able to take on such an endevor, so thanks for that offer.

..dane
 
Why just KyroFlux? Why not the Catweasel or Phil Pemberton's DiskFerret? Heck, as I've pointed out, anyone with any skill with even a moderately slow µC can do the same thing. It's not rocket science--any microcontroller with a "capture mode" timer can do it.
 
]Why just KyroFlux? Why not the Catweasel or Phil Pemberton's DiskFerret? Heck, as I've pointed out, anyone with any skill with even a moderately slow µC can do the same thing. It's not rocket science--any microcontroller with a "capture mode" timer and some access to a chunk of RAM can do it.
 
I was under the impression taht Catweasel was no longer being produced. And I've never heard of DiskFerret. But let me clarify that I'm after a particular goal (playing my old games on a USB stick rather than a floppy disk), and am just starting this research. I know very little of KryoFlux, Catweasel, or DiskFerret. By the tone of this thread it sounds like all of those are physical reading devices. So here are my questions:

1) Do each support reading diskettes with all currently known protection schemes (overlapping sectors, "bad" sectors, etc [I'm sure you could go on here a LOT more than I!])?

2) Do any of them support an archived file format that could be used in creation of a floppy emulator that properly handled such copy protection schemes?

Those are my big two questions. I don't see a big point in trying to copy my old floppies if I can't play them. And if they need the original diskettes to be played (either to store data ala Star Fleet circa 1986), or if they need the original to verify a particular disk peculiarity, then what's more important is emulating those features. And if those features can't be emulated, then I'm not sure where to go next.

I'm all for looking into emulation. But before entering the tunnel I'm trying to find out if there is a light at the end, or an oncoming train. :)

..dane
 
Jens still shows the Catweasel MK4Plus on his website

All record the time of each flux transition. Phil's DiskFerret design uses an FPGA in addition to a PIC and can go fast enough to record data from MFM hard drives. It's also the most expensive.

In a microcontroller, you set a timer to running with the "capture" feature latching at every read data edge (pulse). You then stash the value of the counter (or the difference between the last count and the current one, your choice) in RAM and keep going. If you know the modulation and recording method in advance, you can save quite a bit of storage for samples by classifying the capture events as they arrive (e.g. for MFM, you need only record t, 1.5t and 2t events (2 bits); FM is simply t or 2t).

To reproduce the stream, you pulse the data line using the same scheme. Many uCs have a PWM mode attached to their timers, which makes things a bit easier.
 
Thanks chuck for bringing me up to speed quickly- I appreciate it!

So it seems there ARE hardware solutions out there to read disks. Awesome. Next is the question of using the diskettes once copied. Are you aware of existing software that can emulate a floppy using a flux-recorded file format like IPF? Someone mentioned "PCE" in another forum and I am beginning to look into that. Are there others I should consider? I know about DOSBox, but it does not support the IPF format at this time.

thanks,
..dane
 
Back
Top