Thanks so much for the detailed analysis. It will let me here with two conclusions for me:

1. thanks for the feedback. Much appreciated
2. your 386dx results show me that I might have still some work to optimize. But at the end it might most probably not bypass the performance of smb via msclient on the 386sx. Therefor I will leave it for the moment being.

Again I’m not here to criticize or so - I really like your program a lot. At the end I might not get the results I was „dreaming“ of meaning full usage of the 10Mbit Ethernet power which might netto result in 600kb/s via strong CPUs.

But you’ll never know maybe I will rerun it again later on. I was somehow hoping that „very little overhead“ due to that layer 2 approach would give me lot performance boost compared to quite intensive smb protocol transfers on my 386sx.

Anyway I know there are a lot of other factors speaking for netdrive

I'm not concerned about criticism. But I do want to understand when people are having "a bad time" with the code in case there is a problem.

One more question - where is your SMB server running?

My default smb share runs on a quite low end openwrt router (netgear 6220) with a usb stick w/ ext4 connected

A router with a proper WiFi or Ethernet port running SMB is still going to be better than a $15 RaspPi (2.4GHz only) with a badly implemented USB or Ethernet port. SPI is probably the problem there. For an apples-to-apples comparison run SMB o the RaspPi and then compare to NetDrive or EtherDFS.

At this point try the WiFi on the RaspPi instead of the Ethernet; it will probably perform much better, and it will help EtherDFS too. You can also try a USB connected Ethernet adapter on the native USB port. Avoid the HAT, as that has to go through SPI.

Lastly, NetDrive is not "layer 2" .. it's IP and UDP so it's fully routable. That's not much of an advantage on a local network, but I really do like that routable feature which is why I designed it to use IP and UDP. EtherDFS is truly layer 2.

1. chapter: I agree
2. chapter: usb ethernet connect might be worth it. Remember that I can’t access my rasp via wifi from my 386. I also experienced that etherDFS isn’t routable and even can’t survive wifi to lan „conversion“
3. chapter: of course true my fault

I'm confused about point 2 though ... Your RaspPi on Wifi is connected to a router and the 386 is connected to the router, right? At least NetDrive will work in that setup because it is routable. It's just EtherDFS that needs a fully wired path on the same LAN segment.

The Ethernet HAT satisfies the need for a wire but a USB connected Ethernet adapter should be much faster even for EtherDFS.

Good morning.

My working etherdfs/netdrive setup:

386 -lan- rasp w/ usb -wifi- internetrouter (won’t be used here)

My smb setup:

386 -lan- openwrt router w/ usb -Wifi- internetrouter (won’t be used actively here)

Heya, mbbrutman!

Thank you so much for all of the hard work on creating mTCP NetDrive so far! I really appreciate it! 😀

What I would like to see is having the starting drive letter when loading NETDRIVE.SYS in the CONFIG.SYS file. For example, my Toshiba Tecra 500CDT has drive letters D: occupied for a PCMCIA CF card, E: for the CD-ROM and drive F: for the RAM Disk and starting drive letter G: would be for NETDRIVE.SYS. I would love it if we could have a option to set the starting drive letter when loading NETDRIVE.SYS.

What do yo think? ^^

Sorry, it can't happen. I think it's even discussed earlier in this exact thread.

When DOS installs a device driver it tells the device driver the first drive letter that it has been assigned. The drive letter is assigned by DOS and it depends on the hardware found on the machine and the other device drivers that were loaded first. The device driver has no control over it. DOS 2.0 doesn't even tell the device driver what the drive letter is. You have to play games to figure that out.

There are programs that allow you to load device drivers later after the boot is complete and even assign drive letters. I haven't found one that works. Those programs needs to muck with DOS internal data structures and even though NetDrive is as simple as it gets those programs are missing something important.

A trick that helps:

In order to reserve a drive letter in DOS for CD-ROMs, networks, etc., you may quite easily create as many tiny dummy ram drives as needed that upon boot take the needed drive unit letters for themselves, only to release them manually from the command line when needed, by invoking its unloading mechanism or a tool such as KILLDRV.

I personally use this trick quite often, in my case for running programs which were badly hardcoded to only run from a D: drive, which is usually associated with CD/DVD drives which I don't have on many of my systems.

I have found that DEVLOAD can try to load mTCP NetDrive in the AUTOEXEC.BAT, but it hasn't been thoroughly tested and may eventually not work correctly, if not at all. For example if drive C is the boot drive and drive D is the CDROM drive, loading NetDrive with DEVLOAD after MSCDEX in the AUTOEXEC.BAT file would obviously assign it as drive E.

However, I found that loading NetDrive with DEVLOAD can be quite a risk.

A better way would be to load Drive Letter Manipulator in either CONFIG.SYS or AUTOEXEC.BAT file: https://sta.c64.org/dlmanipdoc.html

I'll look into the documentation to see how it all can be done. 😀

I've posted a small update to the device driver. This version has a work-around for the 3C905 packet driver, which was crashing when I tried to send an ARP response from the device driver under the timer interrupt. This bug was baffling, as no other packet driver had a problem with this code. (I suspect the 3C905 packet driver is using uninitialized storage, but I haven't been able to prove it.) If you have one of these cards you want this code. Otherwise, getting this code won't hurt you but it is also not going to do anything for you.

Now that I have that problem under control I plan to go back to the 'Go Back' feature and finish that off. The ability to do something to your storage and then be able to easily undo it should be very handy, especially when experimenting with old shareware.

anderswk wrote on 2024-02-20, 19:43:

Very cool project and super useful.

I tried it on my PS/2 Model 35 and it worked perfect.

However on my newer Aptiva system (P5 133 + 3com etherlink 100 pci) I get a hang. It happens after I issue the netdrive connect command. The command seems to finish okay and returns to the command prompt, but then ~10s later it freezes. Rest of mtcp suite works fine.

I was able to recreate this problem and I've spent the past few weeks working on it. If you are still interested, download the latest code mentioned in the post right above this one and your PCI system with the 3C905 card should work.

It's a long story, but I think the packet driver is beyond buggy. The crash was caused when I sent an ARP response under the timer interrupt, which is a perfectly valid thing to do that no other packet driver has problems doing.

mkarcher wrote on 2024-02-23, 02:32:

anderswk wrote on 2024-02-21, 17:00:

Packet driver is "3Com EtherLink PCI Bus Master Packet Driver v5.2.6", 3C90XPD.EXE.

The most recent 3x90XPD drivers are just broken in multiple ways and are best avoided. If you don't have a 905C, "downgrade" to earlier versions of the packet driver or use a different ethernet card. You might also try a setup with an ODI packet driver layered on top of a 3COM ODI driver. Spurious lockups and crashes with 5.2.6 are not surprising. I reverse engineered enough of exactly that driver version to give up on the idea of "just fixing" it.

You'll find this thread interesting: https://forum.vcfed.org/index.php?threads/wha … 77/post-1386346

The last post from me has the NetDrive code that crashes it, and the slightly different work-around that allows it to work. It strongly supports your theory that the packet driver is just buggy.