Some step further in MTRR under v86 mode weirdness:

Japheth: JEMM isn't involved, AFAICS, since it has no control of what bits a DPMI host might set in page tables.
You could try to use HDPMI instead of the DOS4GW DPMI host and see if that makes any difference. HDPMI doesn't set the "write through" or "cache disable" page table bits for DPMI function 0800h (map physical device).

Yes!
When I loaded HDPMI32 -r then DOS4GW games benefits from MTRR WC speed up!
Unfortunatelly it's not compatible with Yamaha's DSDMA.EXE. When I load it after HDPMI32 it cancel the speed up effect. If I try to load HDPMI32 after DSDMA then HDPMI32 prints nothing and is not loaded.

So question remains - what changes when HDPMI32 -r is loaded for DOS4GW programs? I still can see DOS4GW startup message but I would expect that it forwards DPMI requests from the application to loaded DPMI server. OK, then there must be something different with memory mapping function that DOS4GW does differently than HDPMI32/CWSDPMI.

Don't know why, but I got several display errors after I activated write combining in Dos on my P2-233 with Voodoo3.
I'll have to check out how my current retro-setup reacts when wc is activated. (Celeron300 MGA100a+Voodoo1)

RayeR wrote:

Unfortunatelly it's not compatible with Yamaha's DSDMA.EXE. When I load it after HDPMI32 it cancel the speed up effect. If I try to load HDPMI32 after DSDMA then HDPMI32 prints nothing and is not loaded.

Aureal Vortex 2 DOS sound emulation has a similar issue with the CWSDPMI extender. When I replaced CWSDPMI with DOS32 it worked again.

RayeR wrote:

So question remains - what changes when HDPMI32 -r is loaded for DOS4GW programs? I still can see DOS4GW startup message but I would expect that it forwards DPMI requests from the application to loaded DPMI server. OK, then there must be something different with memory mapping function that DOS4GW does differently than HDPMI32/CWSDPMI.

I believe DOS4GW will use DPMI over VCPI when it detects a DPMI host. Without a DPMI host DOS4GW just uses VCPI from your emm driver and if nothing, just XMS/INT15h.

Id try rebinding dos4g apps with wdosx (stubbit) or pmodew instead.

Is using MTRRLFBE same as setting UCWC in bios?

Baoran wrote:

Is using MTRRLFBE same as setting UCWC in bios?

It should, some smart BIOSes have this option but I have seen it very rare. And this should be job of BIOS to properly initialize HW but BIOS writers are lazy of legacy stuff...

BloodyCactus wrote:

I believe DOS4GW will use DPMI over VCPI when it detects a DPMI host. Without a DPMI host DOS4GW just uses VCPI from your emm driver and if nothing, just XMS/INT15h.
Id try rebinding dos4g apps with wdosx (stubbit) or pmodew instead.

Yes I guess too. I works the same with cwsdpmi -p except it consume much more low memory than hdpmi32. But I wonder if old dos4gw would manipulate PAT (page attribute table). No speed up with use of DOS32A.

BTW DSDMA.EXE does a lot of weird things. After it's loaded some programs doesn't run or are unstable. E.g. DJGPP GCC compiler crashes with internal; compiler error when trying to compile simple c file and some demos that uses pomde/w crashes/hangs. Without DSDMA they run fine. Aren't there leaked sources of DSDMA? Maybe it should be reviewed and fixed for better compatability on modern HW.