SweetLow

Much simpler. All Windows 9x users now is 40+ old by default, no need to verify anything

It is pretty simple as I said. You can see examples in NVMe sources (I don't want to use Windows 98 DDK Libs too). There you will find exactly PageModifyPermissions declaration and macroses to access PTE. And as I said too - feel free to ask me any implementation if you have problem. IDK do you need this, may be you are interested to write code yourself but nonetheless. P.S. It's curious that in the end I do not need any cache control in NVMe but exactly this thread pushed me to know this fact. Conditional defines and abstraction level work well, I assume you know this. But in this project you can simply implement any NT function you need in version for 9x. And yes, as I remember you expressly stated that you restricted your target to 9x now.

Yes. Just to note - I usually do not go to the next problem before solving previous. You asked for few possible allocators of buffers with needed cache attributes but I slightly misunderstand now - did you try any of them? MS right on the link you gave in this thread recommends to use WC buffer and memory barriers. I assume you try to check this variant.

Looks like you have near to zero observation skills That of course tells enough but not in your favor.

There https://rloewelectronics.com/distribute/WDMEX/0.3/ I could not find them. If some other location exists, please, be gentle to point me. MERCURY127 really posted something like such list from some version of WDMEX https://forum.ru-board.com/topic.cgi?forum=62&topic=28114&start=3160#12 , but there is only names.

No. It does not. I did version of WDMSTUB with this implementation, but did not do "SpecifyCache" part as this function mostly used in binaries because in new DDKs MmMapLockedPages (that is really needed) is just implemented as #define of MmMapLockedPagesSpecifyCache. But it is not hard to do this nonetheless. P.S. It is bad idea to use different cache attributes for different linear mappings of the same physical page. If I remember correctly you can even get Machine Check Exception in such situation if it is enabled. P.P.S. WDMHDA-2026-02-27a - 0E exception (BSOD) on the boot. But version 17 corruption of HDA Controller state is not mentioned now.

Implemented or stubbed? There is no such list in WDMEX.ZIP but I remember that saw this list somewere.

HDA driver model in NT is port/miniport. And HDAUDBUS.SYS is port driver.

http://sweetlow.orgfree.com/download/a20alwon.zip - Added option to automatically detect the "always_on" handler. So there are currently two good options for working in automatic mode: 1. An option with /A20CONTROL:OFF by default. 2. An option to automatically detect the "always_on" handler.

Ok. So I assume you are no less than expirienced driver developer. But why did you ask for help then?

Check that this buffer is properly aligned. It's obvious that it works with aligned buffers only as its parameters are pages, not virtual addresses. But IDK is it working for "partial" buffers - when you reserve large buffer ("pool") and then just take small parts from them. And check the real page attrs (from PDE), of course, in case of any trouble. It is not implemented in WDM and is NT specifiс. But it is easy reproducible through _PageReserve + _PageCommitContig + _PageModifyPermissions or (shorter version) _PageAllocate(PAGECONTIG | PAGEUSEALIGN ) + _PageModifyPermissions

I waited that you running the same in ANY case as I asked you this for your problem insulation, not for my curiosity. But no luck.

$2 USB3.0 UHS-I SD Card Reader + UHS-I Samsung 32G SD Card, Windows 98SE, Nvidia NForce2 (the slowest EHCI controller I know) The same on Windows XP.

I always assumed that turning off EHCI controllers in Device Manager gives the same effect. If you reread the statements of topic starter you will find this one: 150 MBytes @ 60 seconds == 2,5 MB/s. It is simply impossible on USB1 controllers (of course if it measured correctly because some OS options can highly distort usual copy procedure time).

1. You should just ask 2. If in your build environment you can call VXD service (it is possible in .SYS too using some library from Windows 98 DDK AFAIK) then you does not need ASM at all. Else tiny stub is needed only. P.S. Now I at my work environment. The needed function is ULONG _cdecl _PageModifyPermissions(ULONG page, ULONG npages, ULONG permand, ULONG permor); and as I said undocumented but official possibility is two PageCommit flags: #define PC_CACHEDIS 0x00100000 /* Allocate uncached pages - new for WDM */ #define PC_CACHEWT 0x00080000 /* Allocate write through cache pages - new for WDM */ UC cache mode == PC_CACHEDIS | PC_CACHEWT (PAT Index = 3) And on processors with PAT support when MTRR.VXD is loaded: WC cache mode == PC_CACHEWT (PAT Index = 1) in the permor parameter. permand can be 0xFFFFFFFF or ~(PC_CACHEDIS | PC_CACHEWT) - no matter as these flags can be set only and can't be reset.

1. Insulate copy software from picture for the first. Run some disk test like AIDA64 disk benchmark with >64K block size. 2. Check is processor free when copy is in progress by some tool like old Process Explorer.

> Is this chipset PCI\VEN_8086&DEV_06C8="Intel(R) Smart Sound Technology (Intel(R) SST) Audio Controller" ? No. Windows 11 Info: Контроллер High Definition Audio (Microsoft) [System] ** DEVICE: PCI\VEN_8086&DEV_A3F0&SUBSYS_A1841458&REV_00\3&11583659&1&FB ** DRIVER: {4d36e97d-e325-11ce-bfc1-08002be10318}\0035 ** SERVICE: HDAudBus ** MFG: Microsoft ** HARDWAREID: PCI\VEN_8086&DEV_A3F0&SUBSYS_A1841458&REV_00 PCI\VEN_8086&DEV_A3F0&SUBSYS_A1841458 PCI\VEN_8086&DEV_A3F0&CC_040300 PCI\VEN_8086&DEV_A3F0&CC_0403 ** COMPATIBLEIDS: PCI\VEN_8086&DEV_A3F0&REV_00 PCI\VEN_8086&DEV_A3F0 PCI\VEN_8086&CC_040300 PCI\VEN_8086&CC_0403 PCI\VEN_8086 PCI\CC_040300 PCI\CC_0403 ** Registry.MatchingDeviceId: PCI\CC_0403 ** Registry.Inf: hdaudbus.inf:[HDAudio_Device.NT] ** LOCATION_INFORMATION: PCI-шина 0, устройство 31, функция 3 ** MEM: [00000000000000000000000010000011] FE030000 - FE033FFFh, BAR ** MEM: [00000000000000000000000010000011] FE400000 - FE40FFFFh, BAR ** IRQ: [00000000000000000000000000000001] 16, Share, Level Realtek High Definition Audio [MEDIA] ** DEVICE: HDAUDIO\FUNC_01&VEN_10EC&DEV_0887&SUBSYS_1458A184&REV_1003\4&37848E68&0&0001 ** DRIVER: {4d36e96c-e325-11ce-bfc1-08002be10318}\0001 ** SERVICE: IntcAzAudAddService ** MFG: Realtek ** HARDWAREID: HDAUDIO\FUNC_01&VEN_10EC&DEV_0887&SUBSYS_1458A184&REV_1003 HDAUDIO\FUNC_01&VEN_10EC&DEV_0887&SUBSYS_1458A184 ** Registry.MatchingDeviceId: hdaudio\func_01&ven_10ec&dev_0887 ** Registry.Inf: oem5.inf:[IntcAzAudModel.NTamd64] ** LOCATION_INFORMATION: Internal High Definition Audio Bus Audio Intel(R) for Displays [MEDIA] ** DEVICE: HDAUDIO\FUNC_01&VEN_8086&DEV_280B&SUBSYS_80860101&REV_1000\4&37848E68&0&0201 ** DRIVER: {4d36e96c-e325-11ce-bfc1-08002be10318}\0000 ** SERVICE: IntcDAud ** MFG: Intel(R) Corporation ** HARDWAREID: HDAUDIO\FUNC_01&VEN_8086&DEV_280B&SUBSYS_80860101&REV_1000 HDAUDIO\FUNC_01&VEN_8086&DEV_280B&SUBSYS_80860101 ** Registry.MatchingDeviceId: HDAUDIO\FUNC_01&VEN_8086&DEV_280B&SUBSYS_80860101 ** Registry.Inf: oem18.inf:[IntcAudModel] ** LOCATION_INFORMATION: Internal High Definition Audio Bus >Are you using the BIOS CSM or CSMWrap? AMI BIOS CSM

1. No sound on my Core Gen10 system (loops on 16 version). 2. DXDIAG 6.1a works. 3. The last but not least - driver does so INTERESTING thing with hardware that after soft reboot to Windows 11 it does not see HDA controller as available audio device.

Good finding! Any [locked] buffer (page aligned, of course) can be converted to WC (on processors with PAT support, of course) or UC. Undocumented but officially under Windows 98 & ME (WDM case) and direct hardware access under Windows 95. P.S. >Unlike Microsoft I only need the driver to function on x86 But you have to struggle with any hardware incompatibility then.

No, of course. Once again, it just can work in non coherent cache mode. As there is no such thing as snooping on ARM platform for example. P.S. mercury127 system under Windows 10: --- Bus 00, Device 1B, Function 00 - Intel Corporation HD Audio Device (PCIE) --- PCI\VEN_8086&DEV_8D20&REV_05&CC_040300 01(@50) - PCI Power Management (PM) 05(@60) - Message Signaled Interrupts (MSI) 10(@70) - PCI Express (PCI-E) Link Speed @ Width: Gen0 @ 0x 10987654321098765432109876543210 3322222222221111111111----------- PCIECap: 0091h 0000000010010001b DeviceCap: 10000000h 00010000000000000000000000000000b DeviceControl: 0800h 0000100000000000b DeviceStatus: 0010h 0000000000010000b NoSnoop PCI Express Extended Capability List: 0002(@100) - Virtual Channel (VC) / v1 --- Bus 03, Device 00, Function 01 - nVidia Corporation HD Audio Device (PCIE) --- PCI\VEN_10DE&DEV_10F0&REV_A1&CC_040300 01(@60) - PCI Power Management (PM) 05(@68) - Message Signaled Interrupts (MSI) 10(@78) - PCI Express (PCI-E) Link Speed @ Width (Maximum): Gen1 @ 16x (Gen3 @ 16x) 10987654321098765432109876543210 3322222222221111111111----------- PCIECap: 0002h 0000000000000010b DeviceCap: 00008DE1h 00000000000000001000110111100001b DeviceControl: 2137h 0010000100110111b DeviceStatus: 0009h 0000000000001001b PCI Express Extended Capability List: 0001(@100) - Advanced Error Reporting (AER) / v2 Two HDA PCI-E controllers one with enabled no-snoop and one with disabled simultaneously.

The fact that something built as .SYS does not prevent it from using .VXD interfaces. More I can say - it does not prevent from exporting .VXD interfaces. Look at ACPI.SYS for example. Yes, I assume. No. But Windows 9x kernel has enough functionality for any port trapping/injecting into DOS code/interrupt handling chaining you want to use in form of VxD interfaces. P.S. >I don't have much experience or knowledge of x86 assembly. Сalling of vxd interfaces are available in C code of drivers and almost all needed headers exist, of course

>Instance_Table struct from binary dump I can guess that it is not your code rather some array of structures of far pointer (4 bytes) + value (2 bytes), and pointers point to DOS DATA segment (00C9h)

Problem is really strange as for example pangomis'es MSI PRO H610M-B DDR4 (Realtek ALC892/ALC897) with core gen12 has HDA controller as PCI device too. So driver works on core gen8 and core gen12 but does not work on core gen10. But I slightly do not understand why his system did not work on previous versions of driver (if he tested these versions, of course). This one. And SB16 emulation is just bonus in process of finding Registry settings as I paid attention on the string for environment with T6 type and then found variable responsible for switch - that does not export through the Registry key. The fact that SBEMUL sets (null) hook for FM synthesis was the main surprise for me But I don't understand why do you need exactly such thing. You can DISABLE FM synthesis in SBEMUL and enable it anywhere (real hardware or other emulator). P.S. >but couldn't make much sense of the int 20 hooks I did not understand what you are talking about for the first but now I understand. Man, you are in Windows in 386 Enhanced mode These are just VxD calls/jumps. Some disassemblers should understand them (and I wrote few simple tools for decoding them to human readable values).

Ok, I paid few more time as caching theme on x86 was slightly unclear for me (as I learnt this theme more from NT point of view - universal drivers for different architectures). But for x86 things are more simple as there is stated that PCI devices always work in cache coherent mode (as PCI-E devices with cleared no-snoop bit) and chipset is responsible for snooping. It means that all memory buffers can have usual WB chache mode and no explicit software cache control needed. But OTOH it is unclear now why my Core gen 10 system does not work - it has HDA Controller as PCI device - exactly as Core gen8.

Ok, I paid some time to check what happens. With high probability clearing this bit is palliative. It will work only on PCI-E devices. But HDA Controller can be pure PCI device that needs uncached buffers or flushing cache explicitly to work properly with very high probability. And JFYI - older Indel HDA controllers are PCI-E devices but newer (including my test system) are PCI. P.S. And second JFYI - MS driver work with this bit set on.