SweetLow

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip 1. Partial handling of Windows 9x specific requests that use Linear Scatter/Gather buffer. 2. Cut out hassles came from NT code, in particular two or more NVMe controllers should detected and work without problem now.

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.