Why you want NE2000 compatibility? It's better to use a driver made for the hardware instead of the other way around 😉

3Com drivers are very easy to find, and in the case of this Etherlink 2, the drivers are included in the Crynwr packet driver collection (3C503.COM). I don't think it will be as easy to find drivers for that Geniuslan card.

jwt27 thanks for the info, I have downloaded the driver pack you mention... I thought that NE2000 was a standard (like soundblaster for a rough example) to make all various nics of the time more-or-less compatible... I'll give 3C503.COM a go 😀

edit: by looking at the silkscreening of the genius card I found it is the " Genius LAN GE2000II" one that is easy to get the driver for 😀

edit2: I found that "The Last Byte Memory Manager" works fine with the Biotec chipset (rebranded UMB 82C491 as it seems) , so I am happy again 😊
Anyone knows if it's actually possible to register it nowdays? I have googled but found nothing 😒

keropi wrote:

t changing the "F SEGMENT SHADOW RAM" option to Enabled or Cached (it was set at disabled) then the HDD would work fine, even the 20GB one with DiskManager overlay. Here is a BIOS pic with this option:

Now what does that have to do with HDD usage and OS loading?

AMIBIOS stores hard disc configuration in shadow RAM. Therefore, without shadowing the BIOS hard discs don't work. This is obviously a bit obscure, which is why the default is usually for this to be enabled.

Also the available values for this option (and all other Shadow Rams ones below it) are DISABLED / ENABLED / CACHED / IN 486 ... what value should I use? I triead Enabled and Cached and saw no difference (board has 128kb cache btw)

You should probably have C000-C7FF enabled, to shadow the video BIOS.

Anyone knows of a UMB driver/enabler that will work with the Biotec 82C3491 mobo?

Erm, EMM386?

Please press F3 in BIOS to switch from monochrome palette to the more suitable grey/blue palette for color screens. (or stay disco style 😉 ).

F Segment shadow means basically shadowing the BIOS ROM as this is by default at F000. It is recommended to enable it. Also video BIOS at C000 as SarahWalker suggested.

Keep Memory remapping enabled.

For UMBs try QEMM386 / EMM386 for first steps as those are rather well tested and compatible with the old stuff. (before you change to some unknown tools).
I strongly suggest that you use standard programs/drivers/tools for the first system setup before you change to less popular tools.

The URAM complaint about the missing WBINVD (write back invalidate) mnemonic shows that it would like to have a 486. So make sure that the tools you want to use are really still supporting 386 systems.

I see, thanks for the F segment explanation...
I was not clear enough on the UMB driver, I need one other than EMM386 , so that UMB works in XMS-only. The Last Byte works perfect but that shareware delay is bugging me.
It seems strange that URAM needs a 486, IIRC it states in readme that it works in 386 too... at any rate I need to test more stuff it seems.

Just add NOEMS option to the EMM386 line in config.sys and it works in XMS mode only.

But loading EMM386 puts the cpu in v386 mode whether it allocates ram as EMS or not, so it's a no go.
I will stick to using TLB for now until I notice an error or something ...
I'll aslo enable the Video Bios shadowing...
I assume the cached/INTO-486 options refer to the possibility of said shadowed ram to be cached in the 128kb sram or inside the cpu's L1 cache?

as a sidenote, both the 386DX mobos that I own have the BIOS option to enable the cpu's internal cache (a bit pointless I think on the Biostar one that I am using since the 386DX is soldered in place)

thanks again all!

Well could you explain a bit more in detail, why V8086 mode is a no go for you?

If you have at least MS-DOS 6.0 you have the possibility to add multiple boot configurations.
The Virtual8086 mode is one of the innovations introduced with the 80386 CPU.
Also a lot of older games require EMS.

GeniusLan K1306023 is most likely reband of Realtek base on RTL8012, 8019AS chipset

@elianda

Try and run Turrican II for example with EMS. No go.
Also there is a respectable number of other games as well that don't like v386 mode. I am sure you know many as well.
And the most important factor of all is personal preferences. 🤣 I just don't like EMM386 or whatever EMS handler unless I have to use it for something to run.
TLB suits my needs so I'm sticking with it as I have a 2nd hand license now 😊 for the very last (to my knowledge) 2.52 version!

@shspvr:
I actually found the card is a "KYE GE2000III SE" and found the real working packet driver, did a quick test with mTCP and I get ~400kb/s of transfer speed from main pc -> 386pc , not bad at all!
I'll upload the driver diskette to vogons drivers

I made some "heavy usage" this evening... 🤣
Transfered via mTCP ftp server ~1.03GB/10.200+ files with about 390kb/sec (not to shabby!) and did the mandatory Speedsys tests:

I am happy with the setup, a 20GB silent HDD (all smaller ones were too noisy for my taste) , a speed-limited DVD-RW drive working fine and ofcourse FAT32 😀 I slapped a CT-1600 in it too!

DOOM is unplayable btw 😵 😁 🤣 🤣 but Alone in the Dark runs at the correct speed 😅

Hmm something is slow with your memory

yes it is slow as I see now... if you look on the BIOS screen I posted above the defaults that I loaded have 2 W.S. for DRAM... I'll change it since it is most likely the culprit ... I have installed 8x1MB 70ns simms IIRC
I was running Alone In The Dark and got a hard lock when the "chicken monster" breaks the window... I rebooted and removed ctmouse from memory (since I have no mouse attached for now and it was loading in COM1) but I was getting some weird gfx errors like some stuck pixels or floating polygons in AITD... Checkit utils also fail the memory test, I assume a SIMM is bad or something , I run MEMTEST 86+ now and suddenly the HDD is working? 🤣 strange

here is Speedsys with 0WS and lowest possible timings:

I think that the bandwidth in summary has to do with memory size or something... it's not logical you have almost double while the detailed graph is almost identical (or perhaps I am reading it wrong)

I also re-sitted the ram sticks, maybe something was a little wrong as now checkit utils complete succesfully the mem test... or the contacts had some dirt, I'll do a detailed cleaning job I think just to be sure 😊

yep, there is definitely something wrong...

Carnby shouldn't be on the table 😵 😁 🤣 🤣

I am using 8 of these simms, all are identical, I assume they are not compatible with the mobo....

I did more tests today.... apparently the ram chips were not to blame because Checkit fails with every ram I tried... I even tried the 2nd 386DX mobo and had the same failure. I assume that checkit it does not like DOS7.1 ...
The AITD gfx corruption was because I had 0WS enabled in the VGA VRAM. I lost ~2mb from vram speed in speedsys but it's better to be compatible than fast 🤣

@elianda
Was the speedsys image taken when an FPU was installed, or in absense of an FPU? If it was taken with an FPU installed, can you run another Speedsys test without the FPU installed? I'm wanting to see how the complete absense of an FPU is artificually inflating SpeedSys scores.

Doom should be absolutely fine on a DX40 - I played and finished it on an SX40 when it originally came out (one notch down from full screen), so yeah, definitely something wrong somewhere!

well in my 386 it runs at 10-12fps , personally I find this unbearable ... back in the day I bet I would play it but now there is no way

feipoa wrote:

@elianda
Was the speedsys image taken when an FPU was installed, or in absense of an FPU? If it was taken with an FPU installed, can you run another Speedsys test without the FPU installed? I'm wanting to see how the complete absense of an FPU is artificually inflating SpeedSys scores.

We had a discussion about this already in the 386DX-40 thread:
386DX40 build

For me it is difficult to remove the FPU in this system since it is in a case with a lot of cards installed and a bunch of cables....
But since Keropi has also a 386DX-40 the score would be very much the same without FPU.
For speedsys it would be much better to give a separated Integer and Floating Point Score (CPU/FPU).

That's 21 pages of glory I'll need to spend an evening reading through, which I will do, just not at the moment. I'm really just trying to find out if removing an FPU artificially inflates the speedsys scores. If that is the case, I cannot rely soley on keropi's FPU-less Speedsys score, I'd need to test this theory on the same system, FPU-installed, FPU-removed.

I can test for this myself as well, but I had just put away my 386 system and will have to retrieve it.