Mov AX, 0xDEAD

driver is too complex, need reverse how it works, i dont know how it inject own code to kernel context switching, probably PsSetCreateThreadNotifyRoutine(), PsSetLegoNotifyRoutine(), KeSetSwapContextNotifyRoutine() do this job for x64 need rewrite it fully, so much easy to hack existing x 64 kernel code instead write new "x32 avx enabler" has small asm source (FASM syntax), anyone can improve my inject code or rewrite for x64 (after finding where to store/load 256 additional bytes) inject.asm

1) struct _CONTEXT has unused 1a0 bytes, it is enough to store high part of ymm0-ymm15 (low part of ymm* is xmm* and stored by kernel itself) struct _M128A VectorRegister[26];// Offset=0x300 Size=0x1a0 2) struct _KERNEL_STACK_CONTROL has embeded _XMM_SAVE_AREA32 union, no enough space to store high part of ymm0-ymm15 regs I dont sure what struct used on x64 to store FPU context, if _XMM_SAVE_AREA32 - need to expand struct (200h->300h) and change all related size/offsets in kernel, finding these places may be very hard, see KxContextToKframes(), KiInitializeKernel(), KiInitializeContextThread(), PspGetSetContextInternal(), RtlInitializeContext(), KeSaveLegacyFloatingPointState(), ...

avx1/2 on x32 are 8 256-bit registers YMM0-YMM7 avx1/2 on x64 are 16 256-bit registers YMM0-YMM15 x64 user applications can use all 16 registers, this is problem, 16*256/8= 512 bytes to store all x64 avx1/2 registers

There is no free space in thread context to store all x64 AVX registers, no easy way to make it same as x32 version.

@daniel_k I fear problem may be in different dsdt place, before checking in VM i ask you to do one more modification Errors: ParseArg(PCTXT pctxt, char chArgType, POBJDATA pdataArg): aml bytecode: So: 1) ParseIntObj return AMLIERR_INVALID_OPCODE 2) ParseString return AMLIERR_INVALID_OPCODE 3) *pctxt->pbOp is not OP_BUFFER () or OP_PACKAGE() because no call to PushTerm() 4) _DSD definition has OP_PACKAGE (0x12) , i dont see problem with it Couse we dont know exact dsdt place i recommend to edit ParseArg() to write unknow opcode with nearest bytes to log:

@daniel_k first error: prev parsed thing: of object: DSDT: i think problem is _ADR 64-bit integer, acpi failed to parse it 0x0E is new acpi 2.0 opcode AML_QWORD_OP, my patch already support this opcode, but ParseIntOb() cannot parse it sucesfully: I will test this new way of name definition on VBox to check what is wrong with ParseIntOb()

error in StrCpy(), it try to show endless string, In StrCpy() + StrLen() remove lines to enable debug output i have old sp1->sp3 sources, but you need compile it yourself, see PM for link

@daniel_k this log doesn't have info about c0140001 AMLILoadDDB is parent wrapper on AML Interpretator, error can be anywhere before you can enable more debug options, but log will be HUGE, probaly you never see end of it ! example of custom DSDT under VM in extended debug mode ParseIntObj()/ParseString() and many other functions output more info to enable patch trace.c to

you can kernel debug TXT setup too just prepare .ISO with kdnet files and edit txtsetup.sif to enable kernel debugging like boot.ini i didn't tested but seems to work

add to boot.ini to stop loading XP before you select something, if it not works, you have wrong boot.ini or multi copies on separate drives

Curently YES, until someone found another XP A5 BSOD ACPI.sys x64 is not much tested, it may have some undiscovered bugs

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

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.