DOS ain't dead - Dif. MTRR WC setting behavior under v86-question for Japheth

RayeR

CZ,
29.12.2018, 01:11

Dif. MTRR WC setting behavior under v86-question for Japheth (Developers)

Hi,
FalcoSoft from VOGONS discovered (and I confirmed that) a strange behavior of DOS programs using LFB when MTRR WC setting is appllied under v86 mode. All you know well my MTRRLFBE tool. It can run under realmode as well as in v86 mode (JEMM/EMM386 doesn't matter what mmgr). It does its job to set MTRRs. Under real mode all games and apps benefits from significant speed up that WC mode brings. But under v86 only SOME programs make speed up. I discovered that modern programs and game engines like QDos, Q2Dos and Hexen II compiled by DJGPP that use a DPMI server makes speed up even under v86 while older games like Blood, Duke 3D or profile benchmark from SciTech tools that use DOS4GW extender doesn't make any speed up. This is a question for true memory management expert :) I suspect that it may have something to do how the extender maps physical LFB address to linear address of the application. I never wrote a program with Watcom C for DOS4GW but I suppose it has something similar to __djgpp_map_physical_memory (that is alias to a DPMI function) and it might do things different way.

So how to fix this problem? Do we need some update of DOS4GW (or DOS32A?) or can it be fixed in JEMM?

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
30.12.2018, 19:48

@ RayeR

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

> So how to fix this problem? Do we need some update of DOS4GW (or DOS32A?)
> or can it be fixed in JEMM?

I have no idea how this could be "fixed" in Jemm. I vaguely remember that the address ranges in the MTRRs are physical addresses, aren't they?

---
MS-DOS forever!

RayeR

CZ,
31.12.2018, 17:09

@ Japheth

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

> I have no idea how this could be "fixed" in Jemm. I vaguely remember that
> the address ranges in the MTRRs are physical addresses, aren't they?

Yes, all this adresses - LFB base returned by VESA info and MTRRs are physical.
There's one more thing - caching modes (Write combining, etc.) are also affected by PAT (Page Attributes Table) and I know that PAT has higher priority than MTRR ranges (if the same area is defined as WC in MTRR and WB in PAT, then WB wins). My MTRRLFBE changes only MTRRs and don't touch paging tables. Maybe there is some difference how CWSDPMI, DOS4GW and JEMM handles paging tables (if they touch them) and how physical address is mapped to linear address...

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
01.01.2019, 14:12

@ RayeR

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

> Maybe there is some difference how CWSDPMI, DOS4GW and JEMM
> handles paging tables (if they touch them) and how physical address is
> mapped to linear address...

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

---
MS-DOS forever!

RayeR

CZ,
01.01.2019, 23:10

@ Japheth

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

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

OK, how can I do it? Is it enough to load HDPMI permanently with -r ? Or do I need to modify game stub code?

---
DOS gives me freedom to unlimited HW access.

RayeR

CZ,
04.01.2019, 05:58

@ RayeR

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

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.

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
04.01.2019, 09:34

@ RayeR

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

What happens if you load HDPMI32 with parameters "HDPMI32 -r -a" ?
What happens if you preload not HDPMI32 but CWSDPMI ? (cwsdpmi -p)

---
DOS-u-akbar!

Japheth

Germany (South),
04.01.2019, 19:29

@ RayeR

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

> Yes!
> When I loaded HDPMI32 -r then DOS4GW games benefits from MTRR WC speed up!

For full compatibility you should load hdpmi with options -r and -i. However, this won't affect the dsdma incompatibility.

---
MS-DOS forever!

RayeR

CZ,
05.01.2019, 04:40
(edited by RayeR, 05.01.2019, 05:14)

@ Japheth

Dif. MTRR WC setting behavior under v86-question for Japheth

Post reply

It behaves the same with
cwsdpmi -p
and
hdpmi32 -r -i / -a
except cwsdpmi eats much more low mem.
With use of DOS32A there's no speed up.

---
DOS gives me freedom to unlimited HW access.