• Please review our updated Terms and Rules here

ethflop - a network-backed floppy emulator for DOS

I still like my solution ;)

As others have said a disk change facility would be nice. Nothing elaborate - maybe something like this: All the disks would be placed in one directory and named in some prescribed way (say files are in WIN311 directory and disk are name 01.img, 02.img, 03.img - 11.img you get the idea). Then all the TSR has to do is trap two hot keys (say "ctrl +" and "ctrl -"). The TSR would then step up/down in the file name and load the disk. I am not a programmer so I am not sure how much bigger this would make the TSR's footprint. However, it should be less then a routine that pops up a dialog box asking for the name of the image each time. Of course it would be limited to install disk sets but that is when you would need it most.
Click to expand...
 
mateuszviste said:
Your method would certainly work, I simply consider it bad design to run daemons in foreground and (even worse) expect them to have any kind of direct user interaction. That is why I was suggesting a separate tool that would feed ethflop-server with specific control instructions. It should be fairly easy to extend the ethflop (DOS) tool for that (but could even be web GUI in some "deluxe" version). The limitation of doing this in the ethflop client is of course that then one would require another DOS machine for controlling the eject/insert actions, that is why a separate Linux program might be more desirable.



I agree that quick and dirty hacks are usually easier/faster to create than elegant solutions, yes. ;-)
Click to expand...

I appreciate your candor and I agree with your thoughts. My initial view was that I would generally just use ethflop when I'm installing software and wouldn't leave it running at other times so starting it up in non-daemon mode would be fine. That being said, leaving it running and then just loading/unloading images via a separate tool is a better approach. I was also thinking that a web solution would be great but that isn't nearly as quick of a change.

I will press-forward on the initial proposed changes to the ethflop server to make sure I understand how it's working (and also given that I'm almost done). After that I think it should be straight forward to write a separate tool using unix domain sockets to communicate with the ethflop server (although linux programming is new to me this something as simple as a command line tool to eject/load seems pretty simple to implement).
 
superjer2000 said:
I appreciate your candor and I agree with your thoughts. My initial view was that I would generally just use ethflop when I'm installing software and wouldn't leave it running at other times so starting it up in non-daemon mode would be fine. That being said, leaving it running and then just loading/unloading images via a separate tool is a better approach. I was also thinking that a web solution would be great but that isn't nearly as quick of a change.

I will press-forward on the initial proposed changes to the ethflop server to make sure I understand how it's working (and also given that I'm almost done). After that I think it should be straight forward to write a separate tool using unix domain sockets to communicate with the ethflop server (although linux programming is new to me this something as simple as a command line tool to eject/load seems pretty simple to implement).
Click to expand...

Well I got the modified ethflop server version working. It’s pretty much as I outlined before - if you run the server with the no daemon option once you insert a disk into a client the server brings up a menu of clients with loaded disks and then you pick a client which then brings up a menu of available disk images. If you run it with the daemonize option there are no changes.

For my use case it worked great - I was able to install WordPerfect 5.1 from the 12 or so disk images by just swapping images from my MacBook set up beside my 5150. I still have a few minor things to clean up but this is likely the easiest way for me to install software now. Awesome tool - thanks again for making this available.
 
keenerb said:
Are your changes available anywhere?
Click to expand...

Yes - I was just cleaning up some of the changes I made. I just used it to install Windows 2.0 - worked great.

Attached is the source and adjusted Makefile for the DiskSwap version of ethflop

The readme contains the relevant information on the changes made. Note as per the readme that the ncurses library is required.

I think I covered off the all of the required license-related elements regarding software modification - let me know @mateuszviste if anything else is to be done and thanks again for ethflop - it truly is an incredible accomplishment.

Let me know if it works for you.
 

Attachments

  • ethflop-diskswap.zip
    19.4 KB · Views: 22
keenerb said:
No change to the client/MSDOS app? It detects the changed floppies without any problems?
Click to expand...

Correct it just watches for the control packets that are sent to the server by the client when new clients connect, disks change etc and then presents a refreshed list of clients.

The version I uploaded doesn’t actually require you to ever insert a disk from the client. As soon as a client connects you can select it and then select an image. I found this quicker then inserting a floppy from Dos as I don’t need to list the images and then type the image name I just select the image number from the list.
 
keenerb said:
No change to the client/MSDOS app? It detects the changed floppies without any problems?
Click to expand...

I think I misunderstood your question at first. The DiskSwap routine does the same eject and insert process that would have happened if it was client initiated so from my testing it’s been seamless.
 
superjer2000 said:
I think I misunderstood your question at first. The DiskSwap routine does the same eject and insert process that would have happened if it was client initiated so from my testing it’s been seamless.
Click to expand...

Seems like I can only use disks with less than 8 characters for a name through your local interface.
 
superjer2000 said:
Yes - I was just cleaning up some of the changes I made. I just used it to install Windows 2.0 - worked great.

Attached is the source and adjusted Makefile for the DiskSwap version of ethflop

The readme contains the relevant information on the changes made. Note as per the readme that the ncurses library is required.

I think I covered off the all of the required license-related elements regarding software modification - let me know @mateuszviste if anything else is to be done and thanks again for ethflop - it truly is an incredible accomplishment.

Let me know if it works for you.
Click to expand...
I'm not able to build your package on a new Raspbian install.

gcc -O2 -std=gnu89 -lncurses ethflopd.c -o ethflopd /usr/bin/ld: /tmp/ccXmLcmW.o: in function `sigcatcher': ethflopd.c:(.text+0x74): undefined reference to `endwin' /usr/bin/ld: /tmp/ccXmLcmW.o: in function `printCurrentClients': ethflopd.c:(.text+0x1218): undefined reference to `printw' /usr/bin/ld: ethflopd.c:(.text+0x1264): undefined reference to `printw' /usr/bin/ld: ethflopd.c:(.text+0x12b4): undefined reference to `printw' /usr/bin/ld: ethflopd.c:(.text+0x12e4): undefined reference to `printw' /usr/bin/ld: /tmp/ccXmLcmW.o: in function `main': ethflopd.c:(.text.startup+0x10): undefined reference to `stdscr'

Is that an ncurses issue? I've got the same ncurses packages installed on this new 64-bit system as I had on the old 32-bit raspbian install.
 
keenerb said:
gcc -O2 -std=gnu89 ethflopd.c -o ethflopd -lncurses
This fixed the compile.
Click to expand...

Glad you got it working. I hadn't received any notices of replies to this thread and hadn't logged in for a while.

On the 8 character limitation: It's been a long time since I looked at this but my recollection is that the actual ethflop is limited to 8 characters and the diskswap version doesn't change any of the related routines, it just presents the images on the Linux box.

I haven't actually installed any new software on my 5150 for quite some time so I'll need to fire this back up again at some point as I recall there were a couple of bugs (I think sometimes the list of disk images didn't properly refresh). If you're finding the diskswap routines helpful and you notice any operational bugs let me know and I'll try to have a look.
 
Anyone know how to get the Ethflop non-standard disk images to mount under Dosbox-X? That would be really helpful to integrate my dosbox retro experience with my physical Tandy and 486 systems. The 1.44mb image is fine, but the larger disks aren't working properly.
 
keenerb said:
Anyone know how to get the Ethflop non-standard disk images to mount under Dosbox-X? That would be really helpful to integrate my dosbox retro experience with my physical Tandy and 486 systems. The 1.44mb image is fine, but the larger disks aren't working properly.
Click to expand...
You probably won't be able to use them as "floppies", but the images should work if you mount them as a hard disk.
 
After a couple of years I have update the ethflop project. Released today new versions of both the client (ethflop) and the server (ethflopd).

On the client side, not much changed - the retransmission routine is more robust now. If ethflop does not receive an answer, it retries after 250ms, and then again every 440ms until the 2s timeout is reached. This makes ethflop much more resilient on laggy networks and sluggish hardware.

On the server side, the major development is that it can be run on a DOS machine now. The DOS version of the server (ETHFLOPD.EXE) comes with a user interface that allows to switch floppies on clients. This DOS version is somewhat experimental but it works well for me. I was able to run an ETHFLOP server on a 386SX PC with 640K of RAM and serve floppy images to two DOS clients simultaneously. It's not very fast, but it works. I will likely continue working on this DOS version to improve it further.

 
mateuszviste said:
On the server side, the major development is that it can be run on a DOS machine now. The DOS version of the server (ETHFLOPD.EXE) comes with a user interface that allows to switch floppies on clients. This DOS version is somewhat experimental but it works well for me.
Click to expand...
Thanks, this sounds great! Unfortunately for me what I really want is the user interface on Linux, but perhaps I can run this under emulation :D

It looks from the code like ETHFLOPD.EXE doesn't run as a daemon (I guess the DOS equivalent would be a TSR) but I seem to recall you didn't like the idea of the Linux version staying in the foreground and being interactive in the same way, so I assume that your changes don't bring us much closer to a similar user interface for Linux? Except if I recall correctly there wasn't previously a way for the server to tell a client that a disk had been changed outside of its control, and I assume you must have added that now?
 
doshea said:
It looks from the code like ETHFLOPD.EXE doesn't run as a daemon (I guess the DOS equivalent would be a TSR) but I seem to recall you didn't like the idea of the Linux version staying in the foreground and being interactive in the same way, so I assume that your changes don't bring us much closer to a similar user interface for Linux?
Click to expand...
It does, actually! Although there is no immediate usability gain for the linux version of ethflopd, I did reorganize the ethflopd code so it is much more modular, with clearly separate "UI" and "CORE" parts. The "CORE" part now exposes a few function calls, which makes it easier to develop platform-dependent UIs. For the time being I am focused on the DOS server, but I do plan to come back to this "UI on Linux" subject later. It would not be similar to the DOS thing, though. The DOS version is a full screen application because there are no "services" in DOS (and running ethflopd as a TSR would be very unreasonable). The linux version would be a command line tool that communicates with the ethflopd daemon over a unix control socket (and then this tool could be used by any other fancy UI, be it console based or web based or whatever else, but that's not something I will do myself).
doshea said:
there wasn't previously a way for the server to tell a client that a disk had been changed outside of its control, and I assume you must have added that now?
Click to expand...

There is no way for the server to actively push such information to the client, BUT there is actually no need for such mechanism. When a physical floppy is ejected, there is nothing that tells the running programs about it either. There is, however, an int 13h mechanism that allows an application (or in practice - DOS) to query a floppy change status line. This is supported by ethflopd - so if the program/OS asks, ethflop with answer "yes, floppy has been changed since last time". In practice this works well, because DOS is very careful about this and queries the status line often.

Back to the "UI on Linux" subject - I have nothing concrete for you yet, sorry - but on the short term you might indeed emulate a DOS ethflopd server on Linux using QEMU or DOSEMU2 or maybe even VBox, making the emulator hook a linux tap interface and then bridge this interface with your physical NIC. I did not test it, but it should work. And on the longer term, "stay tuned". ;)
 
The current svn (trunk) version of ethflopd for linux supports diskettes switching, as well as a few other actions. The ethflopd binary acts as a "client" when executed with the -c switch. This switch allows to pass a control commands for selected MAC addresses. This control communication happens over a UDP socket on localhost. Answers are JSON-encoded in case anyone would like to create some nifty GUI around this.

usage: ethflopd [options] interface storagedir
ethflopd -c control query

Options:
-f Keep in foreground (do not daemonize)
-h Display this information

The '-c' mode is for sending control commands to ethflopd on behalf of
an ethflop client. Possible queries:

imglist returns the list of available floppy images
clilist returns the list of clients
e MAC eject floppy used by client MAC (format 00:11:22:33:44:55:66)
i MAC DNAME insert floppy image DNAME to client MAC
I MAC DNAME same as 'i' but inserts the floppy img write-protected

svn code can be fetched with this (on linux):
svn checkout svn://svn.code.sf.net/p/ethflop/code/ ethflop

Formal release to be expected within a few days.
 
ethflopd ver 20240916 released today.

Code: 
ver 20240916
 - floppy images of non-standard sizes (>2.88M) are created thin-provisionned
   to avoid ethflopd becoming mute for several seconds while zeroing data, esp
   relevant for the DOS version on PCs with slow I/O)
 - Linux version: "client mode" (ethflopd -c) to query and control the daemon
 - Linux version: lock file no longer used, replaced by a UDP/1390 socket
 
mateuszviste said:
Answers are JSON-encoded in case anyone would like to create some nifty GUI around this.
Click to expand...
Nice! I'd like to write a UI if I can find the time. My dream:
- ability to connect user interface to ethflopd, Bochs, qemu, other things where I might wish to change floppy images
- ability to jump to the next image with a single key press
- perhaps some play list feature, where you can skip to the next image in a list with a single key press, and that list might repeat some disks for those annoying installs like OS/2 (although obviously I won't be installing OS/2 using ethflop!)

I feel like I should actually write something in plain C with ncurses so that the interface's requirements don't exceed that of ethflopd, which I imagine can run on some pretty old Linux distributions?

Also, just curious, what's your goal for declaring ethflop to be version 1.0?
 
You must log in or register to reply here.
Back
Top