Ran into the same problem. Got around it by making a couple of local
modifications to fdnet.bat as indicated by the REMs and arrows below.
Put your appropriate packet driver in the second local mod. The packet
driver (3c90xpd.com) was placed in the same directory as all the other
packet drivers, C:\fdos\network.
This is not an ideal solution because the mod must be manually restored
each time the network package is updated. Make sure you keep a backup
of fdnet.bat because this file will be overwritten on update. This mod
will be slightly different for different vendor and device IDs.Also, you
have to find the numbers for berndpci to use. My PC running FreeDOS
also boots Linux, so I was able to get the numbers from there using the
following command (I googled nic vendor device id grep to find the
command).
|lspci -nn -vvv | grep Ethernet|
. . .
:vmGeneric
REM
---------------------------------------------------------------------------
REM Cut and Paste from CONNECT.BAT
REM
---------------------------------------------------------------------------
REM *** Local modification for Dell Dimension 8100 BEGIN <===<<<
berndpci 10b79200 <===<<<
if errorlevel 1 goto 3c90xpd <===<<<
REM *** Local modification for Dell Dimension 8100 END <===<<<
berndpci 10222000
if errorlevel 1 goto pcntpk
berndpci 10ec8139
if errorlevel 1 goto rtspkt
goto qemu13
REM *** Local modification for Dell Dimension 8100 BEGIN <===<<<
:3c90xpd <===<<<
3c90xpd.com /I=0x60 <===<<<
sleep 2 <===<<<
goto finish <===<<<
REM *** Local modification for Dell Dimension 8100 END <===<<<
. . .
On 3/15/2021 5:11 PM, Jerome Shidel wrote:
Hi,
On Mar 15, 2021, at 7:12 PM, Eric Auer <e.a...@jpberlin.de
<mailto:e.a...@jpberlin.de>> wrote:
Hi!
If that means that fdnet knows which driver WOULD match
a given PCI ID, could it DISPLAY that info and let the
user dig up the recommended driver manually? What does
the current fdnet version do in such cases, silently
load another driver in the hope that the hardware would
actually be virtual, matching one of a small set of
standard drivers? Even then, it should probably be more
explicit about what is happening :-)
Your giving FDNET far to much credit.
It only tests the type of Emulator and CPU type. There is an issue in
the CPU detection provided by V8Power tools. Basically, It reports all
real hardware as “Other Emulation.” I need to fix that (eventually,
hopefully sooner rather than later). When real hardware & CPU are
detected (like I said--broken at present), FDNET will just exit saying
it doesn’t support that at present.
Otherwise, FDNET.BAT is basically just wrapped around an excerpt of
CONECT.BAT from Rugxulo’s MetaDOS.
Take a look, there isn’t much to it.
https://github.com/shidel/FDNET/blob/master/FDNET/BIN/FDNET.BAT
<https://github.com/shidel/FDNET/blob/master/FDNET/BIN/FDNET.BAT>
(Newer than the one in 1.3-RC3)
I’m no DOS Networking expert.
I’d be happy have someone take the time and make FDNET better and add
more supported hardware.
Although, in the meantime, I should probably update the package
description for it to say — “Mostly to provide basic networking
support for virtual machines (like VirtualBox and VMware)"
And as Dean hints,
if the user already has loaded ODI drivers, fdnet could
detect that and load a WRAPPER, without requiring extra
hardware drivers, as the ODI drivers already are there.
Regards, Eric
I use FDNET as-is in VirtualBox and on VMware.
However on my 486 and PentiumPro, I just use it to set DHCP with “call
FDNET.BAT DHCP” after I load the vendor Packet Drivers for my NICs.
:-)
Jerome
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
