Mov AX, 0xDEAD

Стерегущий, лучше используй сборки с уже интегрированными файлами, тут в основном тусовка экспериментаторов или разработчиков/моддеров

After re-enable UAA device and getting sound, offset 0x55 is always =1 ? if YES, it is difference to my H110, i always have =0, it means PMEE=0 always after UAA was re-started or started first time or never started this bit is changed after re-enabling UAA on my h100, this may occur: 1) hdaudbus.sys (vanilla v5.10.1.5013 size=144382 from sp3) itself clears bit or 2) ACPI+DSDT code clears bit or 3) HDA controller itself clears bit after programming by UAA driver

@Dietmar On you screen PMEE=1 (0x55=0x1) with sound and without PMEE=0 after loading windows to desktop with enabled or disabled UAA Controller on my H110 PMEE=1 can be only after seting this bit manualy, PMEE automaticaly cleared when i reenable UAA device in device manager Also on your "NoSound" screen RW Everything still detects CodecID=10EC0269, it means HDA bus is active, but maybe RW uses different way to look for HDA devices. Reselect PCI device in RWE to re-read actual state after disable/enable in Device Manager When UAA controller disabled in device manager, RW Everything stop detecting HDA devices

my mistake, 0x4c+0x9 = 0x55, field definition is right on Flex DSDT

0x54 is not recognized

@Dietmar You can check PCI regs with RW Everything about PMEE and PMES bits when driver started and when not Select HDA controller, offset 0x4C+ 0x9, bit 0 and bit 7 Intel PDF tells Power Management Control And Status at offset 0x54 for 110 and 370 chipsets, my 110 DSDT confirm it: 0x54 = 0x08, PMME=0 PMES =0

@Dave-H Microsoft UAA High Definition Audio is driver for HDA controller integrated to Southbridge/PCH When it started, it look for any devices on dedicated HDA bus, each device on Bus has VEN_ID & DEV_ID (similar to PCI) Realtek audio chip answer to Bus, microsoft UAA driver detect it and load vendor driver based on VEN_ID & DEV_ID Vendor's HDA drivers usualy installed as START = MANUAL, so realtek driver never started without UAA driver before

Hi All 1) Little analyze of INT32/ULONG using in XP acpi sources Windows 7 decompiled acpi.sys: 2) Windows 7 x32 driver probably has problem with accessing 64-bit values from/to memory in ReadSystemMem()/WriteSystemMem(). It doesn't read/write high 32 bit, set it to ZERO instead

Chipset/CPU emulators based on PCEm run at "original" speed, they try to emulate Time and Instruction Set of CPU 8088/../Pentium2 exactly

Updated to v5, two fixes BSOD 0xA5 (0x0000000D, ..., 0x4449555F, 0) absence _UID method BSOD 0xA5 (0x11, 0x08, ..., ...) error in _AMLILoadDDB() (Connection() opcode)

There is no universal way to jump over unsupported bytecode In case of Connection() i made decision to keep field definitions because it was used in other place In case of doubled device definition i jump over all definition to end in case of I2cSerialBusV2()/GpioInt()/GpioIo() currently no need any fixes, because XP acpi.sys skips this type of resources as "unknow" I don't know all new acpi v2-v5 sub-opcodes inside parent commands because it requires reading and comparing all acpi specification (1000 pages)

You need manually parse every motherboard For my h110 s2pv board, you need "hide" IICB method of PCI device because it uses I2cSerialBusV2 + probaly link to I2C0 device Then need to hide CLP0 device + LNK0 device + ....

See how DSDT coded in bytes fix detect sequence 02 11 (connection as buffer), skip all inside buffer definition and jump to 53 48 53 33 01 to same in decompiled format: now SHS3 is not alias to GPIO pins, now it is alias to fake memory field

New "global" 12 acpi 2.0 commands like ToHexString() in v6666/v7777 works as expected, when you comment it, you broke codeflow, in your example you never call THDS() on XP. It is wrong way, i dont want talk about it.

Sorry, i don't read this thread because i feel NDSI6 can not be ported this way, main problem is netio.sys, it offers some new fuctionality

@Dietmar Connection() fix, change ParseField() to Tested on DSDT test code: SHS3 and FLD0/FLD1 are dummy with undefined type, if DSDT uses it lately in some math calculation, i don't know what happens

@Dietmar Same way as double devce definition was fixed, jump opcode pointer to next object Just wait fix in few days

Easy-Peasy way: skip GpioIo definition and assume SHS3 as memory field To: I know this is wrong, OperationRegion can be NULL or dummy, but we don't have any GPIO support in acpi.sys anyway GeneralPurposeIo = 0x08, missed in XP acpi.sys

Ignoring Connection broke access to SHS3 from other part of DSDT to parse this new opcode, Win8 acpi.sys has new ParseFieldConnection((_ctxt *pctxt, XXX *pConnection)) to store connection config, _FieldDesc has new fields, last field has variable len: I think these new fileds used in some field functions read/write/access to connection alias SHS3

Thanks, usual acpi.sys compiled with deep optimization, unknow mixed register/stack calling convection, hard to decompile

Hi Can someone share ACPI.SYS Windows 8.0. or Windows 8.1 x32 checked version ? (from checked installation ISO)

XP lacks Connection (0x02) opcode in ParseField() Basicaly GPIO will never(ACPI v5.x standart) work in XP, we will have only interpreter bypass fix

Thanks I think acpi.sys get crazy on Connection or GpioIo decoding, these two comands are "macro" and coded by some way DefField := FieldOp PkgLength NameString FieldFlags FieldList FieldOp := ExtOpPrefix 0x81 5B 81 FieldOp 33 PkgLength 47 50 4F 32 GPO2 01 FieldFlags (ByteAcc, NoLock, Preserve) 02 FieldList: FieldElement := NamedField | ReservedField | AccessField | ExtendedAccessField | ConnectField ReservedField := 0x00 PkgLength AccessField := 0x01 AccessType AccessAttrib ConnectField := <0x02 NameString> | <0x02 BufferData> ExtendedAccessField := 0x03 AccessType ExtendedAccessAttrib AccessLength 11 26 0A 23 8C 20 00 - Buffer ()

Raw table please, not decompiled

@Dietmar GPO2 and next object seems as AML garbage, need DSDT/SSDT dumps to clarify