SweetLow

VIA VT1708B 8-ch @ nVIDIA MCP78 Driver installed and loaded, but I got only errors on any device access (like general error). WDM audio stack is working (I tested USB audio device).

It's excuse for alpha version but not for beta or release. As the [WDMPNPB003_Device.FactDef] section and other sections in HDA.inf too. Two controls (low and high "something", I don't remember exact names) are definitely visible and, yes, do nothing. P.S. Realtek ALC887 @ Intel Comet Point-V PCH (Intel Core gen 10 Desktop Motherboard) CSM does exactly the same job as at my notebook - all PCI devices on IRQ11. Version 11 of drivers set up without problems. Situation is exactly the same as MERCURY127 have - digital part of driver definitely works as expected but no analog sound. >low and high "something" Low and High Frequencies, I suppose (I have localized Windows).

Yes, this probably is result of hang on when installation of bad driver was executed. One file from WDM sound system was absent (and did not restore on subsequent driver installations), that gave such undesirable effect. Ok, I tested more. WDM SB emulation is working (Quake1 as test software). DirectX diagnostic tests of (non hardware accelerated) Sound and Midi passed. One small problem exists - there is no Volume Mute enabled control, only Level. Individual components like Wave or Midi have both Level and Mute.

Now no hang on. Device is OK in Device Manager. But on the first step device does not work as expected - no sound. It shows in Multimedia but does not allow to select itself as audio output device. Ok, this is very base system installation. So I tried to setup DirectX8.1 and lo and behold - sound arrived. I did not do full tests (l will do lately) but it's working. Drew Hoffman, do you need tests on other systems (on Nvidia HDA controller and on Intel HDA controller, but I don't remember what codecs there are)?

No, you don't. NTSTATUS InterruptServiceRoutine ... if(!that->AcknowledgeIRQ() ){ return FALSE; }

Check that you handle only YOUR interrupts and pass all other to system. You have to check some bit(s) responsible for indicating IRQ in controller register(s). Ok, I will try to do standard sequence Disable Controller - Reboot - Run DbgView - Enable Controller, But as it hangs probability to success not high.

Intel Sunrise Point-LP PCH - High Definition Audio Controller + Realtek ALC236 (Intel Core Gen 8 Notebook) (and HDMI Audio codec on the same HDA controller too). After installation of driver: With Normal boot temporary hangs on during the boot and then reboot. With Logged boot just hangs on with these last lines in BOOTLOG.TXT: [000FF0E5] INITCOMPLETE = mmdevldr [000FF0E5] INITCOMPLETESUCCESS = mmdevldr [000FF0E5] Loading PNP drivers of WDM Sample Driver for HD Audio (PCI\VEN_8086&DEV_9D71&SUBSYS_84A6103C&REV_21\BUS_00&DEV_1F&FUNC_03) JFYI, on this system CSM programs all PCI devices to one IRQ11.

It is.

Yes. I have two systems with native NVMe support in CSM and only one can boot - HP notebook on Core gen8 with InsydeH2O UEFI BIOS. But to do so I pushed to write my own DDO as in real mode this BIOS has bug which failed any Int 13h read or write on request with more than 8 sectors. No one bootloader can boot with such restriction and MS bootloader BOOTMGR that WRITES into file system under some circumstances can corrupt this file system even. Int 13h on Core gen10 on mobo with AMI UEFI BIOS does not work at all in Virtual 8086 Mode. And this is "must have" feature to boot any system that relates on this mode in boot time/work time icluding Windows 9x, Safe Mode of Windows 9x and DOS in protected mode with EMM386 or somthing like this. This problem is not new, RLoew faced with those buggy BIOSes with his AHCI driver too as the root of problem is the same - PCI Bus Master Controllers including ATA, AHCI and NVMe have identical program model of the I/O request: SG List pointing to the I/O buffers. There is solutions (double buffering) which can struggle with I/O buffers in the "wrong" memory but no one solution can solve the problem of SG List in the "wrong" memory as no one software except the driver itself "knows" about this list. So to solve the problem you have to replace buggy code of Int 13h handler in form of 1. new CSM DXE module, 2. DDO that supports NVMe or 3. driver in form of .SYS or .TSR

This is not my question there but thanks in any case.

This is NT driver, not for this section.

Release: https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip https://github.com/LordOfMice/Tools/blob/master/nvment.zip https://github.com/LordOfMice/Tools/blob/master/nvme2k-src.zip readme: NVMe driver for Windows 9x. Base: nvme2k 1.0.0.2 https://github.com/techomancer/nvme2k Changes: Port for Windows 9x, 64-bit LBA & Fixes 1. Generic - added SCSI 64-bit LBA commands processing (large drives support). Tested on Windows 9x ONLY - fixed controler shutdown code - speed up of command queueing and it is less CPU consuming - fixed enormously low speed or false positive errors on executing of large size requests - various code rectifications 2. Windows 9x specific - port with 2 bug fixes - install script nvme9x.inf written Install and uninstall as usual hardware, nothing specific.

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.