ethflop - a network-backed floppy emulator for DOS

[mateuszviste]

Today I published a new DOS tool: a "virtual floppy over Ethernet", targeted to ancient PCs.

ethflop is a DOS TSR that emulates a floppy disk drive. The emulated (virtual) floppy disk is, in fact, stored on a Linux server as a floppy image. All the communication between ethflop (the TSR) and ethflopd (the Linux daemon) is exchanged over raw Ethernet.

homepage: http://ethflop.sourceforge.net/

ethflop can be used as a mean to copy data from one PC to another (instead of using physical diskettes, you use virtual network floppies - faster, easier and more reliable). It can also be used as an easy mean to create backup images of existing floppies, using diskcopy. And of course, it can also simply act as a permanent storage for a retro computer - the biggest floppy disk ethflop is capable of emulating is 31M big.

It works on 8086-class machines, and the TSR's resident size is under 2 KiB.

 

[Caluser2000]

Cool. Whats wrong with ftp?

 

[daver2]

That's cool for the DOS world. Nice job.

FTP requires the operator to type commands to transfer a file from one computer to another.

Software programs (that expect a floppy disk drive to work) cannot just be made to work with a separate program (ftp in this case).

If the network drive looks like a regular floppy drive, then any software that uses a disk will not notice any difference in operation at all, despite the fact that the media that it is actually reading from/writing to is not physical media stored locally but virtual media stored remotely on a server.

Dave

 

[Caluser2000]

That's cool for the DOS world. Nice job.

FTP requires the operator to type commands to transfer a file from one computer to another.
Dave

There are GUI options to do ftp transfers.

 

[Stone]

There are GUI options to do ftp transfers.

In DOS?

 

[glitch]

Cool project, especially nice that it can handle much larger floppy images! And, being layer 2, you're not likely to be exposing your machine to any sort of Internet-exploitable vulnerabilities if you just leave it running.

 

[Caluser2000]

In DOS?

Last I looked ftp was two way thing.

 

[glitch]

So, does the image end up being just a raw filesystem-in-a-file, like when you make a floppy image with dd? If so, can even the larger ones be mounted under Linux?

 

[Chuck(G)]

How about IMD support? N.B. IMD accesses the FDC directly.

 

[mateuszviste]

Cool. Whats wrong with ftp?

FTP si cool, but it is limited to copying files back and forth. Not much of use if you have a diskless system.

ethflop is not that much about copying files (even though it can be used for such use), as it is about accessing remote data transparently without the need to copy everything locally. For instance, you can't run software from within a FTP server.

An example of how I use ethflop: I have a few programs and games on floppy images. Let's imagine I'd like to edit a spreadsheet with As-Easy-As: I mount the virtual floppy containing As-Easy-As, run it from there, do my thing, done. I can do this from any DOS PC in my LAN, and my spreadsheets will always kept on this one (virtual) diskette, always up to date.

If the network drive looks like a regular floppy drive, then any software that uses a disk will not notice any difference in operation at all, despite the fact that the media that it is actually reading from/writing to is not physical media stored locally but virtual media stored remotely on a server.

Exactly correct.

So, does the image end up being just a raw filesystem-in-a-file, like when you make a floppy image with dd? If so, can even the larger ones be mounted under Linux?

The resulting images are exactly in the same format as what Linux creates with dd. It's basically a raw, sector-by-sector image. You can mount such images in Linux, or access them with mtools, or even feed ethflop with your own, already existing floppy images.

How about IMD support? N.B. IMD accesses the FDC directly.

If I understand correctly, ImageDisk is some kind of low level floppy-copying software. After a quick web search I could not find any specific information about it, but I assume that it programs the FDC controller directly. In such case, it won't work with ethflop. ethflop is only able to fool software that accesses the floppy drive through the standard BIOS interface (meaning - virtually all existing software, with the exception of some very specialized disk handling tools). You can, for example, copy a physical floppy to/from a virtual ethflop diskette using the diskcopy command. You can also run tools like scandisk or defrag.

 

[keenerb]

FTP si cool, but it is limited to copying files back and forth. Not much of use if you have a diskless system.

ethflop is not that much about copying files (even though it can be used for such use), as it is about accessing remote data transparently without the need to copy everything locally. For instance, you can't run software from within a FTP server.

An example of how I use ethflop: I have a few programs and games on floppy images. Let's imagine I'd like to edit a spreadsheet with As-Easy-As: I mount the virtual floppy containing As-Easy-As, run it from there, do my thing, done. I can do this from any DOS PC in my LAN, and my spreadsheets will always kept on this one (virtual) diskette, always up to date.



Exactly correct.



The resulting images are exactly in the same format as what Linux creates with dd. It's basically a raw, sector-by-sector image. You can mount such images in Linux, or access them with mtools, or even feed ethflop with your own, already existing floppy images.



If I understand correctly, ImageDisk is some kind of low level floppy-copying software. After a quick web search I could not find any specific information about it, but I assume that it programs the FDC controller directly. In such case, it won't work with ethflop. ethflop is only able to fool software that accesses the floppy drive through the standard BIOS interface (meaning - virtually all existing software, with the exception of some very specialized disk handling tools). You can, for example, copy a physical floppy to/from a virtual ethflop diskette using the diskcopy command. You can also run tools like scandisk or defrag.

Is etherflop limited by the BIOS-supported floppy drives, or can it be used to add a 1.44mb virtual floppy drive to something that only supports 720kb in bios? Is it significantly faster than a "real" floppy drive?

Will it co-exist with etherdfs?

 

[mateuszviste]

Is etherflop limited by the BIOS-supported floppy drives, or can it be used to add a 1.44mb virtual floppy drive to something that only supports 720kb in bios?

Yes, you can. The machine's limitation is due to hardware limitations of the controller. ethflop operations completely bypass the hardware controller.
My 8086 laptop supports only 720K floppies - but with ethflop, I am able to use a virtual 31M "diskette".

Is it significantly faster than a "real" floppy drive?

To be honest I'm not even sure what throughput is to be expected from a real floppy - the internet appears to suggest something around 40 KB/s. If that's so, then ethflop is three times as fast on my 386SX PC. And of course it highly depends how many times a "real" floppy would have to perform seek operations, these are extremely slow on real hardware and induce lots of latency, while for an ethflop drive they are irrelevant.

 

[keenerb]

Wow, great job! This is REALLY exciting.

I would suggest having the DELETE option prompt you for yes/no if possible.

If the image is altered on the remote side, how does the DOS tsr respond? It might be useful to be able to switch floppies for something like MSBACKUP or installing a multi-disk application like Windows...

 

[Al Kossow]

If I understand correctly, ImageDisk is some kind of low level floppy-copying software. After a quick web search I could not find any specific information about it

search for "Dave Dunfield" and "imagedisk"
the spec for the format has been released

It supports pretty much anything that can be created with a 765 style floppy controller, including mixed sector sizes on a per-track basis

I don't know what Chuck was requesting as far as support

If you're using the BIOS, it obviously is limited to the floppy types it supports

at best, you're going to be limited to 8/9/16 sectors/trk and 2 sides

the bios has no limit as far as number of tracks? I'm not quite sure I understand how you can create usable file systems larger than 2mb without
pretending it's a floppy tape drive with existing drivers

Remote use of IMD would be very handy, but this program ain't that.

 

[mateuszviste]

IWill it co-exist with etherdfs?

Yes. You can simultaneously use both, and copy data between each other.

I would suggest having the DELETE option prompt you for yes/no if possible.

Good idea, yes. I was planning for an interactive question anyway to allow 'stealing' a virtual floppy that has been left in another computer.

If the image is altered on the remote side, how does the DOS tsr respond?

You should really avoid accessing ethflop disk images directly from within the Linux server, at least when said images are being used. Moreover, ethflopd keeps the floppy image file opened as long as it is mounted by a client - so renaming this file won't have any effect, ethflopd will still access the old file through its previous file descriptor.

It might be useful to be able to switch floppies for something like MSBACKUP or installing a multi-disk application like Windows...

This is something I have in my todo list, but if I have to be entirely honest it is not something I really expect actually implementing... Not in the TSR at least. Handling for example hotkeys would make the TSR much trickier (and heavier) than it is. One of ethflop's aspects I really like is its simplicity and size, and I'd like to keep it that way.

But perhaps this could be handled on the server side, through some kind of management interface that would allow to force operations on connected clients (ejecting disks, swapping them, etc...)? Yes, this is definitely something that I might add at some future point.

search for "Dave Dunfield" and "imagedisk"

Found it. The README says: "ImageDisk performs direct hardware access to the floppy disk controller chip", hence as I stated previously - there is no chance it will work with ethflop, it's simply impossible to catch requests to an I/O port from within real-mode software. It would require putting the CPU in protected mode (386+) and trap all I/O signals. Not something I wish to engage into.

If you're using the BIOS, it obviously is limited to the floppy types it supports

It is not, for ethflop doesn't use the BIOS. The applications use the BIOS "CHS" interface, and ethflop intercepts these calls. It acts as an overlay to the actual BIOS, if you will, effectively replacing it for diskette-related operations.

Remote use of IMD would be very handy, but this program ain't that.

That's correct - hardware emulation of a floppy controller is totally out of ethflop's scope.

 

[keenerb]

It seems like the code to "steal" a floppy drive might overlap the code to "swap" a floppy drive, if you're sending the DOS TSR an "eject floppy" packet. Adding an "insert floppy <name>" packet might just be an extension of that.

On the server side, since floppy disks can only be mounted on a single host, you could simply have a "etherflop swap <olddisk> <newdisk>" command, no need to specify the client DOS machine or anything wacky like that.

 

[mateuszviste]

It seems like the code to "steal" a floppy drive might overlap the code to "swap" a floppy drive, if you're sending the DOS TSR an "eject floppy" packet. Adding an "insert floppy <name>" packet might just be an extension of that.

The difference is in usability. Stealing a floppy will be done through command line, while swapping disks, to be useful, would have to happen somehow in background, because at the time the disk needs to be swapped, there is an application/game running and waiting.

On the server side, since floppy disks can only be mounted on a single host (...)

A single floppy can be mounted on an unlimited number of hosts - under the condition that all hosts mount it as read-only (ethflop ip dskname).

 

[mbbrutman]

Can you explain the "floppy" aspect of this? We've talked about using a block mode device driver in the past which would be backed by a raw disk image on a server somewhere. What makes this program behave like a remote floppy vs. just being a remote drive? (In terms of the raw image on the Linux side they are the same thing, right? Except for the partition table that floppy disks generally don't have.)

 

[Chuck(G)]

Well my IMD question relates to one I often received--will this work with my copy-protected floppies? You know--lots of interest from the early game players.

Obviously, the answer is "no". Just wanted to clear that up.

 

[jafir]

"ImageDisk performs direct hardware access to the floppy disk controller chip", hence as I stated previously - there is no chance it will work with ethflop, it's simply impossible to catch requests to an I/O port from within real-mode software. It would require putting the CPU in protected mode (386+) and trap all I/O signals. Not something I wish to engage into.

This is talking about making IMD support reading or writing to the ethflop, but what about the server side supporting the IMD format, in addition to the raw format? Perhaps that might help with the copy protected issue that Chuck is talking about? If the images were originally created on real hardware, then maybe those images could be used, with copy protection intact, on the ethflop?