SweetLow

You can add ::MTRR 5 - Unused msr_set.exe 20B 00000000 00000000 msr_set.exe 20A 00000000 00000000 It will work without this but for clean result. Yes, of course. AMD64 Architecture Programmer's Manual. MTRR (Memory Type Range Registers) description particulary. You should just be a jentleman and don't stop conversation if YOU asked for. Rename this thread to reflect the REAL problem you have, give other people chance to solve the same problems.

Yes, this will work and is good for test. But for constant using call of this .bat file could be put to autoexec.bat True. But the Problem 2 unrelated to vmm4gfix itself in any case.

1. Run this .BAT file before Windows start: @echo off ::MTRR 0 - 256M UC @ F0000000 msr_set.exe 201 0000000F F0000800 msr_set.exe 200 00000000 F0000000 ::MTRR 2 - 256M WC @ E0000000 msr_set.exe 205 00000000 00000000 msr_set.exe 204 00000000 E0000001 msr_set.exe 205 0000000F F0000800 ::MTRR 1 - 512M UC @ C0000000 msr_set.exe 203 0000000F E0000800 msr_set.exe 202 00000000 C0000000 ::set Default Cache Type to 06h WB msr_set.exe /W 2FF 00000000 00000C06 ::MTRR 3 - Unused msr_set.exe 207 00000000 00000000 msr_set.exe 206 00000000 00000000 ::MTRR 4 - Unused msr_set.exe 209 00000000 00000000 msr_set.exe 208 00000000 00000000 then run Windows and if nothing bad will happen show me the output of MTRR_VAR under Windows 2. The default driver behaviour under Windows 9x so disastrous that it overwrites all WB registers from BIOS - so no, under 64-bit OSes all will work fine, BIOS works correctly here. 3. > 00000000BFEF0000 - 00000000BFF00000 : 0000000000010000 2 (Reserved), 64K And just for completeness - you BIOS has the bug described as Problem 2 here: https://msfn.org/board/topic/186768-bug-fix-vmmvxd-on-handling-4gib-addresses-and-description-of-problems-with-resource-manager-on-newer-bioses/

Ok. 1. Select one config (4 or 12 GiB) to continue (and don't change it till the end). 2. Show me results of MTRR_VAR.EXE and EXTINFO.EXE /L (from BURNMEM package) now under DOS, better in Safe Mode Command Prompt.

No. As I expected it IS MTRR problem: this in 4GiB and 12GiB: 00000200 0000000000000006 0000000F00000800 4G @ 0 / WB 00000202 00000000C0000000 0000000FC0000800 1G @ 3G / UC prevents working this: 00000204 0000000010000001 0000000FF0000800 256M @ 256M / WC 0000020A 00000000E0000001 0000000FF0000800 256M @ 3G 512M / WC as I said above it can be corrected, but in this case not so simple as running some tools in automatical mode. And i saw the SECOND problem too: this BIOS does NOT program MTRR to cache memory above 4GiB. This is unrelated to Windows 9x (if you do not use some 64-bit RAM drive like RAMDSK64/RAMDRV4M, of course), but definitely touch any OS using the 64-bit RAM in PAE mode. Are your interested enough to try to correct?

It is not the solution. It is road to solution. Show me results of MTRR_VAR.EXE (under Windows) with 2G and 4G RAM.

Yes. You asked for the help, got recommendation and demonstrated zero reaction after that. I assume you should to know that this is not smart behaviour.

Do you have working PCI IRQ Steering? Do you use jumbo frames on this device,? And yes, I have to note that you didn't share the results of your previous problem solving...

Pure VESA 2D driver does not use WS2.

This is PM handling of ;INT 33 - MS MOUSE v6.0+ - SET LANGUAGE FOR MESSAGES ; AX = 0022h ; BX = language V version accepts 8 [standard] languages, F - 10 (some additional 2 lanuages and IDK what they are). It's strange but the variable where this value saved is referenced from other places in code - but there is only 8 languages processed. No. It is workaround against buggy hardware - some PS/2 5-Button Mice. In addition to standard unlocking sequence of Set Rate 200, 200, 80 it executes (when Registry "Enable Q318307" key is set to 1) nonstandard sequence of Set Rate 200, 200, 60 before standard sequence. But problem still exists - VMOUSE.VXD from Q318307 has version 4.10.2225 (for windows 98SE for exаmple) and previous version from Q254660 is 4.10.2223. So there is no such thing as VMOUSE.VXD 4.10.2224 and that is the real misterious.

It does. Sorry. Typo. It is burNmem. https://github.com/Baron-von-Riedesel/XMSTools There are different internal results for Windows Memory Manager. And using DOS tools has much more strict effect in memory limiting.

If you need to limit memory - use memory limiter: burmem/limitmem/xmsres. Do not use this execept for Safe Mode. But as you use RLoew's patchmem - do not use at all.

Yes. Cache realization in vcache is limited both by physical and virtual memory. And virtual is more restrictive with maximal available values.

Vcache uses system arena with 1GiB size.

Yes. PCI devices have independent resource management (until they emulate some ISA devices with fixed resource set, of cource). There is simply no "alternative address ranges" for PCI devices as there is no "main address range". "boot address range" and "current address range" - and that is all.

Virtual V86 Mode. The same as you are running DOS applications under Windows. It's just the different sources of the same information (and some of them can have bugs too). And yes, search gives the old KB article from MS still: https://support.microsoft.com/en-us/topic/how-to-disable-pci-bus-irq-steering-in-windows-695c360f-1aae-471e-878e-07ff971b8e02

Because modern OSes: 1. Use modern hardware parts of PC by default (IRQ related - APIC and MSI) that make probability of conflict far lower. 2. Can use modern ACPI - which reports used MB resources correctly. 3. Have some differences in behaviour of Resource Manager. 4. Do not have some bugs like this: https://msfn.org/board/topic/186768-bug-fix-vmmvxd-on-handling-4gib-addresses-and-description-of-problems-with-resource-manager-on-newer-bioses/

I know two and recommend only one. And it is discussed right on this forum on the first page - ramdrv4m. Of course. Because Windows is compatible with DOS drives by default.

The only things you really need are .INF, NDIS2 binary and 1 reboot. Windows do the rest as it natively supports NDIS2.

No, it is not only visual. And why do you use DOS solution for Windows 9x? It has native ramdrives.

You need the Windows .INF in addition to NDIS2 or ODI driver binaries. It's pretty easy to do it yourself. This is my .INF for Broadcom "NetLink (TM) Gigabit Ethernet" (PCI\VEN_14E4&DEV_16B5) http://sweetlow.orgfree.com/download/b57_w9x.zip You shoud add your device PCI ID (and name if you need some other name) in appropriate sections.

Check this problem (use translator) and solution: https://forum.ru-board.com/topic.cgi?forum=62&topic=31453&start=100#9 https://forum.ru-board.com/topic.cgi?forum=62&topic=31453&start=120#16 And pay attention to my tool to set/dump MSR/MTTRs state (MTRR_VAR.EXE particulary): https://github.com/LordOfMice/Tools/blob/master/msr.zip to compare the state of MTRRs with 2G and 4G RAM. As you described your problem - no. As I said I suppose now that this is not the problem in DOS or Windows but it can be fixed.

And why do you think that you got exactly memory size problem in Windows after that? This can be really some other problem like wrong MSRs programming by BIOS with large RAM size.

Two usual things to insulate problem from scratch: 1. BOOTLOG.TXT 2. Try to load into Safe Mode.

Usually it is enough if only RAMDRV4M.PDR is changed. But fix of problem with early unload was unusual as it required the change of Registry parameter for controller object...