umbpci.sys is a driver that works with quite some chipsets to map in the upper memory by hardware.
RTFM.
So do not use a memory manager like 386Max etc to fill the umb pages.

retardware wrote on 2019-12-30, 02:49:

umbpci.sys is a driver that works with quite some chipsets to map in the upper memory by hardware.
RTFM.
So do not use a memory manager like 386Max etc to fill the umb pages.

So how is that going to work with getting my CD drive and Mouse to work? And what is the command to type in CONFIG.sys?

Back in the era, I used to use such a thing - but not very often.
Usually, EMM386 was good enough.
"Real mode with UMB" was just one of the options in my multiconfig, and I only used it for some troublesome software which required a lot of conventional memory, and refused to work in V86 mode - I think it was mostly some demoscene stuff.

Normally, the speed difference between Real and V86 is negligible.
V86 gets noticably slower when there's a lot of interrupts, eg. when playing samples through PC Speaker - but you seem to have a Sound Blaster...

Windows 3.1, DOS4GW, and other extenders work in protected mode anyway, so no benefit from Real mode UMB here.

Read the manual that comes with the download. It tells you all you need to do.
Basically load umbpci in config.sys and then you can add a high to everything you load in config.sys and autoexec.bat (devicehigh= / LH)

Bumrusher89 wrote on 2019-12-29, 23:28:

What I know about is when Windows 3.1 was first released Microsoft removed the real mode option, and gave us 386 enhanced mode. And remember when you have to turn off Windows 3.1 to use your DOS applications to work properly? Because of that some protected mode DOS applications use an older extented memory interface called the "Vritual program control interface" for short VPCI. And it is incompatible with Windows 3.1 DOS protection mode interface for short DPMI. VCPI was not chosen to work with Windows 3.1 if you access any older DOS programs from Windows 3.1 that uses a VCPI, it would either hang, freeze your computer, or program, give you errors and causes the DOS software you are using from Windows 3.1 or in protected mode to malfunction and get's stopped by the CPU's security system for violating system integrity. But using UMBPCI.sys can override that. I don't know that's just me talking....

Well, Windows 3.1 supports two operation modes: Standard and 386 Enhanced.
Unlike the omnipresent Enhanced Mode, the Standard Mode does support VCPI and its applications.
In Standard Mode, Windows 3.1 will keep what ever memory manager was loaded before (like a driver for a physical EMS board, for example).
In fact, in Standard Mode, Windows 3.1 is a VCPI client itself. That was one of the reasons it was favoured in OS/2.
(The "Enhanced" mode of WIN-OS/2 was based around a hacked 386 kernal that acted as a DPMI client (instead of being a DPMI host).)
Or let me put it this way - 386 Enhanced Mode contains a copy of an EMM386-style memory manager, which does DPMI but not VCPI.

Q86018: Windows 3.1 Has Limited Support for VCPI
https://jeffpar.github.io/kbarchive/kb/086/Q86018/

Bumrusher89 wrote on 2019-12-29, 23:28:

So what are you thoughts on using UMBPCI.sys? Does it help get some of your DOS programs or games to work properly?
And what are your experiences with this file before when using DOS or Windows 3.1?

UMBPCI is nice for getting free UMBs without having to use some V86 memory manager.
It reuses the memory intended for PCI, thus will work on 586 and a few 486 systems with PCI ("VIP").
All in all, it appears like "real" RAM to the computer, so no trickery and Memory Managment Unit (MMU) is involved.
Pretty much like a real ISA RAM card would look to the system.

Jo22 wrote on 2019-12-31, 14:16:

UMBPCI is nice for getting free UMBs without having to use some V86 memory manager. It reuses the memory intended for PCI, thus […]
Show full quote

UMBPCI is nice for getting free UMBs without having to use some V86 memory manager.
It reuses the memory intended for PCI, thus will work on 586 and a few 486 systems with PCI ("VIP").
All in all, it appears like "real" RAM to the computer, so no trickery and Memory Managment Unit (MMU) is involved.
Pretty much like a real ISA RAM card would look to the system.

Good explanation.

I honestly do not know why the author called the program "...PCI", as it covers even some ISA-only and VLB chipsets that can map shadow RAM.

Actually UMBPCI does simply use the mobo chipsets' shadow RAM function.
It puts "shadow" RAM into the areas between C000-EFFF where it does not find ROMs, and adds that to the UMA MCBs.
And unlike BIOS ROM shadowing, it does not write-protect these RAM areas.

It should be noted there are at least three drivers providing chipset-specific real-mode UMB:
* LastByte
* UMBPCI
* URAM

@retardware Thanks! ^^

Grzyb wrote on 2019-12-31, 17:41:

It should be noted there are at least three drivers providing chipset-specific real-mode UMB: * LastByte * UMBPCI * URAM […]
Show full quote

It should be noted there are at least three drivers providing chipset-specific real-mode UMB:
* LastByte
* UMBPCI
* URAM

There's also another way of getting UMBs in Real-Mode. 😁
- An ISA RAM card, such as the LoTech 1MB card. It can fill the whole first Megabyte with read-/writeable RAM.

Only real drawback is performance. It uses 8-Bit "ISA" (aka PC-Bus/XT-Bus) with its slow clock speed.
Anyway, it still should do *okay* in most cases. DOS and its drivers usually don't require high speeds.
With the exception of SmartDrive and DoubleSpace, maybe.

But even here, the performance penalty of V86 might be more of an overall issue.
Some 386 and early 486 processors are slower if EMM386 is running (later models support VME and other improvements,
though I don't know if they are even used by the old versions of EMM386. QEMM 7.x+ claimed to support that, though).