Content Type
Profiles
Forums
Calendar
Store
Everything posted by 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
-
@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
-
Chipset/CPU emulators based on PCEm run at "original" speed, they try to emulate Time and Instruction Set of CPU 8088/../Pentium2 exactly
-
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)
-
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
-
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 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 ()