ethflop - a network-backed floppy emulator for DOS

[mateuszviste]

Can you explain the "floppy" aspect of this? (...) What makes this program behave like a remote floppy vs. just being a remote drive?

Technically - from the DOS point of view - ehtflop is not a remote drive. A remote drive interacts with DOS through the INT 2F interface, and provides methods for handling files and directories. EtherDFS is such a network drive, and all CD-ROM readers as well.

ethflop provides DOS with an INT 13h block device. It knows nothing about files, it operates only on sectors that are addressed through CHS geometry. The block device emulated by ethflop is:
- appearing under drive A: or B:
- "removable" (medium descriptor 0xFD, 0xF9, 0xF0)
- advertised with a "MEDIA FORMAT" (int 13h/20) pointing to a 360K/720K/1.2M/1.44M/2.88M diskette*

*this is however true only for standard sizes, the bigger sizes supported by ethflop (4M, 8M, 9M, 15M, 31M) does not advertise a floppy media format, so these would be rather considered by DOS as "some removable drive".

All things considered, the difference between a "removable drive" and a "floppy drive" is indeed very slight.

In terms of the raw image on the Linux side they are the same thing, right?

Yes. Except for a few specific bytes in the MBR and (as you noted) the lack of a partition table.

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.

Such games were presumably relying on some odd low-level formatting glitches, and to verify them they had to access the FD controller directly. ethflop does not cover such case indeed.

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?

In most cases - no, they would not. Floppy copy protection is a complex subject and many different methods were used. Most of these methods relied on reading values outside of the data areas of the floppy disk and required direct control of the FDC to do so, because the BIOS interface does not provide any methods for reading non-data values. ethflop does not emulate a FDD controller, hence games using such methods fall into the same category as specialized low-level disk tools.

 

[JohnElliott]

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?

IMD access could probably be done by using LibDsk as a block layer on the server end, but I expect a lot of copy-protected software uses direct hardware access to do non-standard things with the FDC and so wouldn't work with ethflop.

 

[Chuck(G)]

I know all of this and would have been very surprised if you'd have answered in the affirmative. Thank you for confirming that.

Can you handle Microsoft Windows DMF formatted disks or IBM XDF ones? (This is a vintage computer list, after all).

 

[mateuszviste]

Can you handle Microsoft Windows DMF formatted disks or IBM XDF ones? (This is a vintage computer list, after all).

I didn't know about this "DMF" thing until now. My understanding is that it is a simple 3.5" floppy that is formatted with slightly more dense sectors (21 instead 18) and very small FAT12 tables at the expense of huge clusters and a ridiculously small root directory table.

ethflopd does not know how to create such 1680K diskette images, but it seems very easy to add, so I will give it a try.

The IBM XDF is another story - apparently it required some special drivers that interacted with the FDC to achieve variable-length physical sectors, so ethflop is out of the game, since it is not a controller emulator.

But more importantly - what would be the use case for DMF / XDF support?

 

[jafir]

But more importantly - what would be the use case for DMF / XDF support?

The DMF could be used to install software to your hard drive, but without the need to create actual floppy media. You could install Microsoft Office 4.3 on your windows 3.1 computer, without making dozens of floppies. Obviously there are other ways to do it, such as installing from a network share.

 

[krebizfan]

But more importantly - what would be the use case for DMF / XDF support?

Install disk sets were often formatted that way so the use case would be to install over the network or copy all the files to the local hard disk. I don't think XDF was used for anything other than 32-bit OS/2 so the DOS TSR probably won't benefit from XDF support. A few people did XDF or DMF storage of files but those were quite rare. The slow speed of the writing process meant that most preferred to buy a few more cheap disks instead.

 

[mateuszviste]

ethflop supports DMF images now (1.68M and 1.72M). Will be included in the next formal release. In the meantime, one can simply upgrade the Linux daemon by recompiling it from the new ethflopd.c (the DOS TSR is unchanged)

 

[mbbrutman]

I understand the difference between network file systems (the re-director interface) and block devices so I'll ask the question a different way:

If ethflop is providing a block device for DOS to use, what makes it "floppy" oriented?

For example, I think a conventional DOS device driver probably can create a logical DOS drive that is an arbitrary size. RAM disk device drivers are a good example. Is there something about the TSR or the technique that you used that makes you describe it as a floppy block device driver over Ethernet instead of just a generic block device driver over Ethernet?

(And I presume you used a TSR instead of a device driver because you wanted to have a chance to have a packet driver loaded first.)

Is this because you hooked the existing INT13 interrupt instead of providing a device driver loaded by CONFIG.SYS that just presents a generic block device interface to DOS?

 

[mateuszviste]

If ethflop is providing a block device for DOS to use, what makes it "floppy" oriented?

For example, I think a conventional DOS device driver probably can create a logical DOS drive that is an arbitrary size. RAM disk device drivers are a good example. Is there something about the TSR or the technique that you used that makes you describe it as a floppy block device driver over Ethernet instead of just a generic block device driver over Ethernet?

I did answer this question in my previous message, but perhaps I did it in a clumsy way, so let me try again. There are 5 details that make ethflop "floppy-like":
1. when asked through INT 13 "what is your media format", it answers "I'm a floppy" (int 13h/20h)
2. the MBR it generates points to a "medium descriptor" field that says "floppy" (0xF0, 0xFD or 0xF9)
3. the same MBR has its "removable drive" bit set
4. it appears under A: or B:, which is - in the mind of most computer users - associated with a floppy drive
5. the CHS geometry it emulates is the exact specification of standard floppy drives (eg. 80/2/18 for 1.44M)

Is this because you hooked the existing INT13 interrupt instead of providing a device driver loaded by CONFIG.SYS that just presents a generic block device interface to DOS?

Points 2, 3 and 4 could be achieved with a device driver just as well (maybe point 5 too, but I am not familiar enough with the device driver spec to be sure), but not point 1. Is it enough to call ethflop a "floppy emulator"? It believe it is, but that's probably a subjective matter. If you prefer calling it a "generic network-based block device that happen to be the size and geometry of a floppy" - by all means, please do.

ethflop does not intercept I/O calls to ports 3Fx - so it is clearly not a floppy controller emulator. Such emulator would be impossible to do on an 8086 PC without custom add-on hardware. Instead, ethflop emulates how a floppy BIOS driver would behave.

And I presume you used a TSR instead of a device driver because you wanted to have a chance to have a packet driver loaded first.

Yes, the prior presence of a packet driver was a deal breaker for the "device driver" approach, although it wasn't the only reason. A TSR is also much easier to debug, and I wanted to have the possibility to unload it. And of course there is the "I'm a floppy" int 13h aspect.

 

[mbbrutman]

Ok, that makes it more clear - thanks. For the record, I'm not trying to define what it is - I'm just trying to understand what it is, and why the floppy part is so prominent. I understand now.

I think there is a need for something more generic that just provides a logical DOS drive letter using a block device interface, but has it backed by a disk image on another computer on the network. But that is a different project with different requirements and for a different day.

 

[Chuck(G)]

I have another question.

Is this a bidirectional protocol? In other words, can I format and/or write a floppy on the server from a client?

 

[mateuszviste]

I think there is a need for something more generic that just provides a logical DOS drive letter using a block device interface, but has it backed by a disk image on another computer on the network.

It is a need I don't have, but perhaps other people do. That being said, ethflop is able to emulate drives that are up to 31M (these do not advertise themselves as a "floppy" at the BIOS level, even though they use a floppy-like MBR). 31M is a lot of space already for an ancient PC, and you can have many such "floppy-like drives". For bigger needs (multi-GB storage), I believe a block device is wasteful - using a networked filesystem (like EtherDFS) is much more flexible. But again - I say this from my own, certainly biased, experience and perspective.

Is this a bidirectional protocol? In other words, can I format and/or write a floppy on the server from a client?

You can read from and write to an ethflop "floppy", yes. You cannot "format" it, in the strict sense of the word, though. You have to ask ethflop to create a virtual diskette for you first. What you can do, if you really want to, is reformat it afterwards, but only at the logical level (ie. filesystem only, that is "FORMAT /Q"). Example:

ethflop a                <-- loads the ethflop TSR as A: (have to be done only once)
ethflop n2880 MYFLOP     <-- creates a 2.88M (preformated) virtual floppy
ethflop i MYFLOP         <-- "insert" the newly created virtual floppy (now you can use it)
format /q a:             <-- you can recreate an FS of your own, if you'd like to

I do plan to add some kind of "low-level formatting fakery" in a future version, so the user could actually reformat an ethflop drive to a different size (assuming the geometry is one that ethflop knows about), but I consider it in the category of a gimmick.

 

[Caluser2000]

Some users have an aversion to using linux. Is a Windows version in the works? Just curious and it would cover quite a lot of old computer hobbyists.

 

[mateuszviste]

Some users have an aversion to using linux.

And I have an aversion to Windows.

Is a Windows version in the works?

It is not. I don't do Windows. I am not opposed to someone else porting the server daemon to Windows, but I was told (by Windows users) that what I do is not possible in Windows anyway.

Just curious and it would cover quite a lot of old computer hobbyists.

Too bad for them, I guess.

 

[Caluser2000]

Lol. Well that was the answer I expected to get funnily enough.

 

[JohnElliott]

Some users have an aversion to using linux. Is a Windows version in the works? Just curious and it would cover quite a lot of old computer hobbyists.

If they're using Windows 10 they can load the Windows Subsystem for Linux and run the daemon within it

 

[Caluser2000]

I know. I've linux on a few systems. my EeePC would be ideal for the task. I think even the linux sub-system will scare some people off lol.

 

[mateuszviste]

I know. I've linux on a few systems. my EeePC would be ideal for the task.

A raspberry Pi (even an old one) is also a very good fit - plus it is very affordable and ubiquitous nowadays (that's what I use).

I think even the linux sub-system will scare some people off lol.

I don't know what is this "linux sub-system", but I wouldn't bet on it being good enough for ethflopd. The thing is that ethflopd requires access to raw sockets for crafting its own Ethernet frames, that's quite a low-level feature that is not necessarily part of whatever the W10 linux system provides.

I heard that some windows users were able to run ethflopd on a Linux virtual machine under Windows - that's probably the easiest way so far, if one's really stuck with Windows.

 

[Trixter]

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.

How is this better/more desirable than accessing a network drive?

 

[daver2]

>>> The thing is that ethflopd requires access to raw sockets for crafting its own Ethernet frames, that's quite a low-level feature that is not necessarily part of whatever the W10 linux system provides.

Winpcap (or Win10pcap) is the thing to do this. I used it many years ago to talk at the raw level actress Ethernet.

Other libraries are available at the socket level.

Dave