SweetLow

There is Following service on this forum and pretty strange that author of thread with question(s) does not follow his thread.

Ok, as I made all enhancements to the driver which I planned (and some checks of NT version of this driver too) now I have time to test some very strange info that @Omores was the first to discover: On some CSMs Int 13h for NVMe does not work only for Extended version of this service (Functions 4xh Read/Write) and works for Standard (Legacy) under [Protected] Virtual 8086 Mode. I literally could not believe in this stupidity but after my own test on above mentioned system I can say that this is TRUE. What does it mean? You can boot from non LBA (old DOS) FAT versions of MBR partition exactly as Omores did. To fast check that your system has this bug/workaround just run: http://sweetlow.orgfree.com/download/hdsize.zip (if you will get error under Chrome try to copy/past this address into browser address line directly for the second time) HDSIZE.EXE /R1 and HDSIZE.EXE /E /R1 under DOS+EMM386 if you can boot from some other (non NVMe) drive. If you will get error (9 with high probability) on some (NVMe) drive for the first command and no errror for the second then you have exactly such problem.

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip High speed of executing large (>64K) I/O requests. Custom DMA handling instead of using OS service. Large requests (from 64K to max size supported by controller) executed as fast as in NT now.

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip Full handling of Windows 9x specific requests that use Linear Scatter/Gather buffer. Update is recommended. Install either by reinstalling the device or manually copying nvme2k.mpd and nvmevsd.vxd to %windir%\SYSTEM\IOSUBSYS\ The problem and solution are described in detail in https://github.com/techomancer/nvme2k/issues/15 There are no remaining issues, except for slightly slower performance under Windows 9x than under NT. This turned out to be an issue with the implementation of standard OS service for DMA (Bus Master) controllers – it's almost impossible to receive a real requests for the controller longer than 64K over any length of time. Solution is possible, but this would require custom implementation, using non-standard code.

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.