SweetLow

Is something else on this AHCI controller? Especially BIOS controlled drives.

Check your Windows installation then and get BOOTLOG.TXT for the usual first step of course. And may be it is Windows 95 related problem. The last working case I checked - iGPU on Intel Core Gen 8.

It is only YOUR model of using this software. Bare 2D vmdisp9x in VESA mode now works better than VBEMP on the real hardware for example. Not ideally of course, some bugs exist still.

Use the RIGHT version if you need minimal functionality, pure 2D drivers have 348K :) https://github.com/JHRobotics/vmdisp9x/releases/tag/v1.2025.0.119

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.