VOGONS

Common searches


Reply 160 of 196, by Marco

User metadata
Rank Member
Rank
Member

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

1) VLSI SCAMP 311 | 386SX25@30 | 16MB | CL-GD5434 | CT2830| SCC-1 | MT32 | Fast-SCSI AHA 1542CF + BlueSCSI v2/15k U320
2) SIS486 | 486DX/2 66(@80) | 32MB | TGUI9440 | SG NX Pro 16 | LAPC-I

Reply 161 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

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?

Reply 162 of 196, by Marco

User metadata
Rank Member
Rank
Member

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

1) VLSI SCAMP 311 | 386SX25@30 | 16MB | CL-GD5434 | CT2830| SCC-1 | MT32 | Fast-SCSI AHA 1542CF + BlueSCSI v2/15k U320
2) SIS486 | 486DX/2 66(@80) | 32MB | TGUI9440 | SG NX Pro 16 | LAPC-I

Reply 163 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

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.

Reply 164 of 196, by Marco

User metadata
Rank Member
Rank
Member

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

1) VLSI SCAMP 311 | 386SX25@30 | 16MB | CL-GD5434 | CT2830| SCC-1 | MT32 | Fast-SCSI AHA 1542CF + BlueSCSI v2/15k U320
2) SIS486 | 486DX/2 66(@80) | 32MB | TGUI9440 | SG NX Pro 16 | LAPC-I

Reply 165 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

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.

Reply 166 of 196, by Marco

User metadata
Rank Member
Rank
Member

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)

1) VLSI SCAMP 311 | 386SX25@30 | 16MB | CL-GD5434 | CT2830| SCC-1 | MT32 | Fast-SCSI AHA 1542CF + BlueSCSI v2/15k U320
2) SIS486 | 486DX/2 66(@80) | 32MB | TGUI9440 | SG NX Pro 16 | LAPC-I

Reply 167 of 196, by ppgrainbow

User metadata
Rank Member
Rank
Member

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? ^^

Reply 168 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

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.

Reply 169 of 196, by MiNiDOS

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 170 of 196, by ppgrainbow

User metadata
Rank Member
Rank
Member

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

Reply 171 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

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.

Reply 172 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member
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.

Reply 173 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member
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.

Reply 174 of 196, by veelstekel

User metadata
Rank Newbie
Rank
Newbie

Today I tried the newest version of NetDrive on two different computers; but I still get the same errors as before:

Bot computers are booted by PXE (netboot.xyz) and use the UNDIPD (PXE Packetdriver).
- Netdrive.Sys loaded
- Ran UNDIPD 96
- Ran DHCP
- Ran netdrive connect w/o error
- Freeze after approx 3 seconds (Thus I am able to type on the command prompt for a couple of seconds)

Was anyone able to run netdrive in combination with the universal packet driver?
This would allow for a universal nice diskless boot setup.

I.e. My goal is to have one network setup to test an DOS application on multiple systems with one
Read Only drive A: (PXE Boot Image) containing config.sys / multiple boot entries and netdrive
An harddisk with DOS / Autoexec.bat and the test setup.

Reply 175 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

I try to be responsive, but for debugging email works much better - this is an announcement thread with 9 pages, so trying to reload the context of a problem from weeks or months ago is difficult.

Please send an email with your current specific problem and I'll see what I can do. The 3C905 problem was reported to me nearly 2 months ago and I was able to recreate it and work around it but there is a lot of work involved.

Reply 176 of 196, by veelstekel

User metadata
Rank Newbie
Rank
Newbie

For completeness (already sent by mail but also for others; as they might experience the same)

For the Server part I am using a Synology DS220+; running Build April 14 2024.
I created a test image using "netdrive create hd 100 FAT16B test.hd"
I am serving this using "netdrive serve" to host the same.

I have tested the following scenario's

Scenario A (Success):
- ESXi server with MSDOS host, configured to start with PXE using netboot.xyz;
- Using a default MSDOS6.22 startup image; added the netdrive.sys and netdrive.exe from the "2024-05-23" build
- Added netdrive.sys to the config.sys
- Changed MTU for MTCP to 1500
- Added Universal Packet Driver (PXE) to Disk image
- started with:
* SET MTCP=C:\MTCP\TCP.CFG
* DHCP.EXE (success)
* netdrive connect 192.168.2.50:2002 test.hd d:
* Copied around 10M to new D drive

Scenario B (failure):
- Using this motherboard
https://theretroweb.com/motherboards/s/via-epia-m
- VIA Rhine II FAST ethernet card
- Started with PXE with the same image as Scenario A
- Hangs after 3 seconds after: netdrive connect 192.168.2.50:2002 test.hd d:

Scenario C (failure)
- Using an Acer Aspire One a0751h
- Realtek PCIe based card
- Started with PXE with the same image as Scenario A
- Hangs after 3 seconds after: netdrive connect 192.168.2.50:2002 test.hd d:

Scenario D (failure)
- Using an Acer Aspire One a0751h
- Realtek PCIe based card
- Started without PXE; using an ODI Driver and ODIPKT
- Hangs after 3 seconds after: netdrive connect 192.168.2.50:2002 test.hd d:

Scenario E (failure)
- Using an HP T5710 Thin Client (https://www.parkytowers.me.uk/thin/hp/t5710/efficeon.shtml)
- VIA Rhine II FAST ethernet card
- Started with PXE with the same image as Scenario A
- Hangs after 3 seconds after: netdrive connect 192.168.2.50:2002 test.hd d:

Thus so far I have only been able to succesfull run Netdrive in a virtualized environment.

Any suggestions on what could be the issue?
(The weird thing is that HTGET etc. all work fine in scenario B,C & D which seems to rule out any IRQ related issues)

Reply 179 of 196, by jdredd

User metadata
Rank Newbie
Rank
Newbie

Worked like A charm first try.

Windows 11 Host

IBM PS/2 Model 30 - NEC v30 8mhz
Sergey Kiselev's RTL8019 Network card ( NE2000 )
MS-DOS 6.22
Lo-Tech 2mb EMS card

XCopy'd over ~60mb of data and no errors.

Home network setup. All Local.

What is a good way to test speeds in general?

DiskTest by James Pearce won't work, runtime 106 errors. But to be expected probably.... it is not a real drive.

CheckIt won't even see the drive, but even if did, probably same issues as DeskTest.

ChkDsk did run. Even found the messed up file that DiskTest made.

This is really nice to have! Thank you for making this! Between this, USB Floppy Emulator, CH375 USB, my old system has another way to access files easily and about as native to the DOS system as possible.