Cool! Thanks for sharing this with the world! 😀

This makes things so much easier. No GoTek floppy emulator required, and no messing with USB sticks either. Just read the "floppy" straight from the network. Genius!

I wonder if this code could be modified to provide Sound Blaster emulation over a network as well. A Sound Blaster shouldn't be much harder to emulate than a floppy controller, since in both cases, you'd have to handle DMA. Such an emulator could then act as a Pulseaudio client and stream the audio over NTP to an audio-enabled Linux PC running a Pulseaudio server, either a physical machine on the LAN or the host machine running the hypervisor, if the DOS machine is a VM guest.

Did you really have to host this on SourceForge, though? 😒 It's 2019. Why didn't you publish this on GitHub, Bitbucket or GitLab? SourceForge is so tedious and unattractive to use in comparison. Please don't take that the wrong way. I'm impressed with your work, regardless! 😀

digger wrote:

I wonder if this code could be modified to provide Sound Blaster emulation over a network as well. A Sound Blaster shouldn't be much harder to emulate than a floppy controller, since in both cases, you'd have to handle DMA. Such an emulator could then act as a Pulseaudio client and stream the audio over NTP to an audio-enabled Linux PC running a Pulseaudio server, either a physical machine on the LAN or the host machine running the hypervisor, if the DOS machine is a VM guest.

It only plugs into existing high-level interfaces (BIOS/DOS routines, similar to how DOSBox's virtual drives work), it doesn't emulate physical hardware.

digger wrote:

This makes things so much easier. No GoTek floppy emulator required, and no messing with USB sticks either. Just read the "floppy" straight from the network. Genius!

I like your enthusiasm.

digger wrote:

I wonder if this code could be modified to provide Sound Blaster emulation over a network as well. A Sound Blaster shouldn't be much harder to emulate than a floppy controller, since in both cases, you'd have to handle DMA.

Not at all. ethflop does not emulate a floppy controller - what it does, is emulating a floppy BIOS by intercepting int 13h requests. It's a kind of 'overlay' that goes on top of the machine's BIOS, effectively replacing it for floppy requests.

digger wrote:

Did you really have to host this on SourceForge, though? :/ It's 2019. Why didn't you publish this on GitHub, Bitbucket or GitLab? SourceForge is so tedious and unattractive to use in comparison.

ethflop is distributed through its website: http://ethflop.sourceforge.net
Downloading it is as simple as clicking on a single link. What does it matter what the domain name is?

jmarsh wrote:

It only plugs into existing high-level interfaces (BIOS/DOS routines, similar to how DOSBox's virtual drives work), it doesn't emulate physical hardware.

That's correct. ethflop does not have the ambition to emulate a floppy controller - this would be actually impossible on an 8086, since there is no way to trap I/O port requests.

mateusz.viste wrote:

Not at all. ethflop does not emulate a floppy controller - what it does, is emulating a floppy BIOS by intercepting int 13h requests. It's a kind of 'overlay' that goes on top of the machine's BIOS, effectively replacing it for floppy requests.

Ah, at the BIOS level. Got it. 😊

ethflop is distributed through its website: http://ethflop.sourceforge.net
Downloading it is as simple as clicking on a single link. What does it matter what the domain name is?

For downloading the binary releases, you're right, that doesn't matter. I was referring to the hosting of the source code. A modern repository like GitHub makes collaboration and code contributions and such so much easier. I really don't understand why people would still want to use SourceForge for hosting their open source project repositories these days.

But ultimately, it doesn't matter. You made a cool and useful tool and freely shared it with everyone, and the world is a little bit better because of it. 😀

mateusz.viste wrote:

digger wrote:

Did you really have to host this on SourceForge, though? 😒 It's 2019. Why didn't you publish this on GitHub, Bitbucket or GitLab? SourceForge is so tedious and unattractive to use in comparison.

ethflop is distributed through its website: http://ethflop.sourceforge.net
Downloading it is as simple as clicking on a single link. What does it matter what the domain name is?

There was a short period of time where SF was injecting shovelware into installers. They got smacked down hard and ceased the practice, so they're no more problematic than any other hosting service nowadays. I keep a watchful eye on them as I do Github, etc.
https://www.pcworld.com/article/3032490/new-s … re-program.html

As for the UI, it could look like an abomination from Geocities and I wouldn't care. As a hosting service, I care more about safety and reliability.

mateusz.viste wrote:

ethflopd (the Linux daemon)

why not used usual TFTP protocol at server side?
for TFTP is MANY servers exist, not linux only...

TFTP is so basic it doesn't allow random reads/writes, only whole files can be transferred.

jmarsh wrote:

TFTP is so basic it doesn't allow random reads/writes, only whole files can be transferred.

It would also require a full-blown ARP+IP+UDP implementation, significantly increasing the code size, thus memory footprint.

MERCURY127 wrote on 2019-10-09, 12:15:

mateusz.viste wrote:

ethflopd (the Linux daemon)

for TFTP is MANY servers exist, not linux only...

ethflop server is not linux only anymore. It was ported to FreeBSD, DragonFly, OpenBSD, NetBSD, musl / Alpine Linux and macOS. See: https://gitlab.com/mortmann/ethflop

mortmann wrote on 2021-02-26, 00:45:

ethflop server is not linux only anymore. It was ported to FreeBSD, DragonFly, OpenBSD, NetBSD, musl / Alpine Linux and macOS. See: https://gitlab.com/mortmann/ethflop

Excellent work! I have added a link to your gitlab repo on the project's home page.

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 an 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.

https://ethflop.sourceforge.io

Nice to see continued work on this useful project.

Thank you for sharing the fruits of your work with the world. 🙂

digger wrote on 2024-09-02, 22:48:

Nice to see continued work on this useful project.

Thank you for sharing the fruits of your work with the world. :slight_smile:

Thanks for the kind words. I'm glad you like ethflop, despite it being hosted on sf. ;-)

New ethflopd (server) released today.

1ver 20240904
2 - answers are replayed from cache when client retries its query
3 - mounting a floppy with write access is forbidden if anyone uses it already
4 - DOS version: powersaving is optional (/hlt)
5 - DOS version: added the "no UI" mode (/noui)

Heheh, Touché. Scrolling back I see my responses from 5 years ago again. I guess I've gotten more mellow and appreciative since then. 😅

To aid in collaboration, I still think there are much better repositories on which to host open source projects. Especially when you'd like to encourage collaboration by more volunteer developers.

But hey, looking a gift horse in the mouth and all that. Thanks again! 😉

digger wrote on 2024-09-06, 16:21:

Heheh, Touché. Scrolling back I see my responses from 5 years ago again. I guess I've gotten more mellow and appreciative since then. :sweat_smile:

To aid in collaboration, I still think there are much better repositories on which to host open source projects. Especially when you'd like to encourage collaboration by more volunteer developers.

No worries, I understood your point 5 years ago - and I totally agree on the collaboration aspect. It's a matter of priorities, really. Seeking contributors is not on my list of priorities. I fact, when it comes to choosing a home for my (many) software projects, I have only three requirements: must come with a subversion repo (because I have a bad allergy to git), must provide a PHP-enabled web hosting for the project's homepage and must be free with no annoying web ads. Sourceforge is the only platform I know that meets these criteria. Well, there was also OSDN until a year ago, but sadly it died. I am also periodically pondering about self-hosting my own, simpler "forge" to host all my stuff, but every time I drop the idea as I find sysadmining a server to be a really boring occupation.

new version of the ETHFLOP TSR (DOS client) released today.

1ver 20240920
2 - checking that B: is not a phantom drive before hooking it
3 - ethflop signals the TSR's drive letter to the server (nicer messages)
4 - transient code checks the health of TSR's stack (stack overflow detection)
5 - configurable stack size ($1-$9), can lower TSR footprint to 1.4K, see doc
6 - maximum stack usage during TSR lifetime can be consulted via "ETHFLOP !"
7 - when displaying messages, ethflop terminates them with proper CR/LF
8 - env seg in PSP is zeroed before going TSR (just in case, suggested by ECM)
9 - TSR closes all its handles to avoid potential SFT leaks (thx ECM)
10 - improved validation of answer frames (ECM)
11 - versioning scheme changed from x.x.x to YYYYMMDD

The DOS version of the server (ETHFLOPD.EXE) comes with an user interface that allows to switch floppies on clients.

Thanks for the very nice tool! I will definitely test this out!

Just two questions regarding the DOS version of the server.

1. Can it run in a DOS window under Win9x?
2. Changing floppies on the client, will that work if the client is running an install program which is asking the next floppy to be inserted?

vetz wrote on 2024-09-20, 09:20:

1. Can it run in a DOS window under Win9x?

I doubt it. ETHFLOPD for DOS requires a packet driver to send/receive Ethernet frames. I do not think that Win9x provides such interface. A quick web search tells that there is a thing called WinPKT, but it's only for Win 3.x, apparently.

vetz wrote on 2024-09-20, 09:20:

2. Changing floppies on the client, will that work if the client is running an install program which is asking the next floppy to be inserted?

Yes, this is the main use case.

Any chance ethersrv could be adapted as an msdos app as well?