Zitat von diderius6 im Beitrag #32

---

Hi @Mov AX, 0xDEAD
May be, there are only one or two devices on this motherboard, which gives this BSOD with next Bios f20.
And this can be tested, just to switch them off in Bios, if possible.
...
Your BSOD happens because of method _INI.
Have you tested, if this is the only method, which causes Acpi BSOD?

---

Zitat von diderius6 im Beitrag #27

---

And, have you ever had an XP SP3 on a z170 board, where ACPI works without any mod?
This would be very helpfull to understand, which component of the board with BSOD 0xA is faulty in DSDT table,
Dietmar

---

Zitat von deSSy2724 im Beitrag #3

---

Hmm interesting, you mention DOS and 98SE...... is it possible to run games designed for the original DOS or DOS via 98SE? Can you boot DOS from 98SE or does it crash?

---

Zitat von diderius6 im Beitrag #21

---

Hi all,
A lot of work as I see now, changes need to be done in about 600 places as to me Beyond Compare shows.

---

Zitat von diderius6 im Beitrag #19

---

@Mov AX, 0xDEAD
Do you think it is possible, just do make a small hack to acpi.sys in XP SP3, so that it does not worry about "wrong" acpi 2.0 syntax from Bios?

---

Method (ARPC, 4, Serialized)
            {
                ADBG (Concatenate ("NRPN: ", ToHexString (Arg0)))
                Switch (ToInteger (Arg0))
                {
                    Case (0x04)
                    {
....
 

This method ARPC called from other method _INI, so WinXP will parse this part
ToHexString & ToInteger are new syntax, we need to skip it some way.
ToHexString(ARG0) mean ARG0(maybe integer/string) => convert to String=>Concatenate ("NRPN: "+"0xYYYYZZZZ")
ToInteger(ARG0) mean ARG0(maybe integer/string/buffer/etc) "0x000XXYY"=> convert to Integer=>Case(integer expected)
we cannot just skip these command because they are parts of expressions and do some things with converting data/change types
acpi.sys need new logic to skip these command and do equalent actions

2) deny winxp parsing any _INI methods, winxp will skip parsing most of code, but winxp run not only _INI method, theres is other methods and i do not know how, when and what is runned (_sta,_sun,_crs,_srs and many other), and if vendor added debug lines with new syntax (like gigabyte did) to some of these method we get 0xa5 error again.
EDIT: gigabyte used in _crs new syntax too (

Device (EPC)
        {
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                [b]CreateQWordField[/b] (RBUF, \_SB.EPC._Y3B._MIN, EMIN)  // _MIN: Minimum Base Address
 

Also skipping _INI may have some effects with devices.
This method may work for some motherboards without patching acpi tables if vendor not much modified acpi code

Zitat von Pill Monster im Beitrag #24

---

@the_soft45:
HP aren't blocking you. Microsoft are.

---

Zitat von the_soft45 im Beitrag #15

---

@Mov AX, 0xDEAD
Wow, incredible discoveries... I actually found a driver for the HP Wireless Button driver dating all the way back in 2012... maybe that one would work.
BTW, any luck finding the Realtek Bluetooth HWID in there, to see if it's blocked aswell?

---

Zitat von the_soft45 im Beitrag #12

---

@Mov AX, 0xDEAD
I only linked to the version HP offers on their website. It there any way to decrypt it?

---

Scope (_SB)
    {
        Device (WLBU)
        {
            Name (_HID, EisaId ("HPQ6001"))  // _HID: Hardware ID
            Name (PRSN, 0xFF)
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((PRSN == 0xFF))
                {
                    Local0 = Zero
                    ^^PCI0._INI ()
                    If ((OSYS >= 0x07DC))
                    {
                        Local0 = 0x0F
                    }
 
                    PRSN = Local0
                }
 
                Return (PRSN) /* \_SB_.WLBU.PRSN */
            }
 
 

_STA - method STATUS
wlbu - wireless button (?)
PRSN - persistence (?)
OSYS >= 0x07DC mean OS Windows 8+/Win Server 2012+
in case win7(and low) method _STA return PRSN=Local0=Zero, this mean device is not present for OS

Zitat von the_soft45 im Beitrag #8

---

@Fernando as far as I can tell, the devices do not work on W7
@Mov AX, 0xDEAD I think the Bluetooth functionality is software controlled, not hardware in this laptop's case...
I enabled Bluetooth on Windows 10 and rebooted into Windows 7 and nothing.

---

Zitat von Fernando im Beitrag #4

---

@the_soft45:
I do not believe your suspicion, that Windows 7 doesn't detect devices, which are definitively connected with the mainboard. Even Windows XP detects modern hardware and shows them as "Unknown devices", but cannot handle them.

---