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.