Notebook Hardware Control
Home  |  Main  |  Professional  |  Download  |  FAQ  |  Advanced  |  Forum  |  Contact
Notebook Hardware Control advanced information
 
 
 
 
G o o g l e   l i n k s
 
Google
Web www.NotebookHardwareControl.net
Programming the ACPI Control System (open source)
 
With the ACPI Control System you can visualize and control and hardware components like LCD brightness, WLAN, notebook temperature or fan of the notebook.
 
You can upload and download new ACPI Control System open source classes at
Please upload the c# source and xml files compressed with
 
The ACPI Control System is controlled by open source classes with the programming language c#. For each manufacturer and notebook model it is possible to define a new class and adapt it to the notebook hardware easily. The following steps should give you some information how to program the ACPI Control System.
 
1. Create a new NHC ACPI Module for a notebook or desktop
 
 
2. Control the ACPI objects listed in the System Description Table (DSDT) with NHC
 
NHC supports the following functions to control, read and write the objects in the ACPI Namespace:
 
ACPI Control System Methods
 
 
In the ACPI Namespace method objects are similar to function. For example, the _TMP() method returns the thermal zone's current operating temperature. With the NHC ACPI Control System you can call methods with and without arguments. Valid arguments are BYTE (8 Bit), WORD (16 Bit), or DWORD (32 Bit) values/arrays.
 
bool ACPI.METHOD.Call (string method);
 
bool ACPI.METHOD.Call (string method, int[] inArg, int inArgCount, ref int[] outArg, int outArgCount);
 
bool ACPI.METHOD.GetValue (string method, ref int value);
 
bool ACPI.METHOD.SetValue (string method, int value);
 
bool ACPI.METHOD.SetValueWithReturn (string method, int value, ref int returnValue);
 
Examples:
 
 
 
 
bool result = ACPI.METHOD.SetValue ("_SB.ATKD.WLED", 1);
 
-> Method in the source language file (ASL) ACPI Source Language (ASL)

DefinitionBlock ("DSDT.aml", "DSDT", 1, "INTEL ", "ALVISO ", 100925440)
{
    Scope (_SB)
    {
        Device (ATKD)
        {
            Method(WLED, 0x1, NotSerialized)         // <- NHC will call this method
            {
                If(Arg0)
                {
                    Store(Zero, WLON)
                }
                else
                {
                    Store(One, WLON)
                }
                SWSM(0x82, Arg0)
            }
        }
    }
}

 
 
ACPI Control System functions to read and write PACKAGE objects
 
 
In the ACPI Namespace a PACKAGE object is similar to a array of objects. It is also possible to read or write a package with one or more child packages. Note that with the following functions it is only possible to read or write BYTE (8 Bit), WORD (16 Bit), or DWORD (32 Bit) values. It is also possible to read and write PACKAGE objects defined in ACPI methods. The ACPI Control System supports the following function to read or write PACKAGE objects:
 
bool ACPI.PACKAGE.Read (string name, string path, ref int value);
 
bool ACPI.PACKAGE.Write (string name, string path, int value);
 
bool ACPI.PACKAGE.Read (string method, string name, string path, ref int value);
 
bool ACPI.PACKAGE.Write (string method, string name, string path, int value);
 
Examples:
 
bool result = ACPI.PACKAGE.Read ("_TZ.CMP0", "PKG[0].PKG[1].PKG[3]",ref value);
 
bool result = ACPI.PACKAGE.Write ("_TZ.CMP0", "PKG[0].PKG[1].PKG[3]", 0x35);
 
-> Package in the source language file (ASL) ACPI Source Language (ASL)

DefinitionBlock ("DSDT.aml", "DSDT", 1, "INTEL ", "ALVISO ", 100925440)
{
    Scope (_TZ)
    {
        Name (CMP0, Package (0x02)
        {
            Package (0x02)
            {
                Package (0x0A)
                {
                    Zero,
                    0x2D,
                    0x39,
                    0x44,
                    0x54,
                    0x64,
                    0x69,
                    Zero,
                    0x09,
                    0x32
                },

                Package (0x07)
                {
                    Zero,
                    Zero,
                    0x23,
                    0x35,         // <- NHC will read/write the value 0x35
                    0x3F,
                    0x51,
                    0x5E
                }
            },
            ...
            ...
        }
    }
}

 
 
ACPI Control System functions to read and write BUFFER objects
 
 
In the ACPI Namespace a BUFFER object is similar to an array of Bytes (8 Bit). It is also possible to read and write BUFFER objects defined in ACPI methods. The NHC ACPI Control System supports the following function to read or write BUFFER objects:
 
bool ACPI.BUFFER.Read (string name, int index, ref byte value);
 
bool ACPI.BUFFER.Write (string name, int index, byte value);
 
bool ACPI.BUFFER.Read (string method, string name, int index, ref byte value);
 
bool ACPI.BUFFER.Write (string method, string name, int index, byte value);
 
 
 
ACPI Control System functions to read and write NAME objects
 
 
In the ACPI Namespace a NAME object defination is similar to a variable defination. Note that with the following functions it is only possible to read or write BYTE (8 Bit), WORD (16 Bit), or DWORD (32 Bit) values. It is also possible to read and write NAME objects defined in ACPI methods. The NHC ACPI Control System supports the following function to read or write NAME objects:
 
bool ACPI.NAME.Read (string name, ref int value);
 
bool ACPI.NAME.Write (string name, int value);
 
bool ACPI.NAME.Read (string method, string name, ref int value);
 
bool ACPI.NAME.Write (string method, string name, int value);
 
 
 
ACPI Control System functions to read and write FIELD objects
 
 
In the ACPI Namespace a FILED object is a collection of register. The location of a FILED is defined in the OperationRegion object. For Example if the OperationRegion points to the SystemMemory then the registers in the FILED are in the SystemMemory. The NHC ACPI Control System supports the following function to read or write FIELD objects:
 
Note #1:
 
If you read the field by the name you have to specify the name of the filed (and if necessary the path). In this case you don't have to add the name of the Operation Region.
 
Note #2:
 
If you read the Field by offset you have to use the name (and if necessary the path) of the Operation Region to specify the location of the Field.
 
bool ACPI.FIELD.Read (string name, ref int value);
 
bool ACPI.FIELD.Write (string name, int value);
 
bool ACPI.FIELD.ReadByOffset (string name, ref int value, int offset, byte dataSize);
 
bool ACPI.FIELD.WriteByOffset (string name, int value, int offset, byte dataSize);
 
If you read the Filed by the namein the normal way you have to use the Examples:
 
bool result = ACPI.FIELD.Read ("_SB.PCI0.LPCB.EC0.SSTS", ref value);
 
bool result = ACPI.FIELD.Write ("_SB.PCI0.LPCB.EC0.SSTS", 0x7D);
 
-> Field in the source language file (ASL) ACPI Source Language (ASL)

DefinitionBlock ("DSDT.aml", "DSDT", 1, "INTEL ", "ALVISO ", 100925440)
{
    Scope (_SB)
    {
        Device(PCI0)
        {
            Device(LPCB)
            {
                Device(EC0_)
                {
                    OperationRegion(ERAM, EmbeddedControl, Zero, 0xff)
                    Field(ERAM, ByteAcc, NoLock, Preserve)
                    {
                                Offset (0x18),
                        SPTR,   8,
                        SSTS,   8,    // <- NHC will read/write this value
                        SADR,   8,
                    }
                }
            }
        }
    }
}

 
bool result = ACPI.FIELD.ReadByOffset ("_SB.PCI0.LPCB.EC0.ERAM", ref value, 0x19, 8);
 
bool result = ACPI.FIELD.WriteByOffset ("_SB.PCI0.LPCB.EC0.ERAM", 0x7D, 0x19, 8);
 
-> Field in the source language file (ASL) ACPI Source Language (ASL)

DefinitionBlock ("DSDT.aml", "DSDT", 1, "INTEL ", "ALVISO ", 100925440)
{
    Scope (_SB)
    {
        Device(PCI0)
        {
            Device(LPCB)
            {
                Device(EC0_)
                {
                    OperationRegion(ERAM, EmbeddedControl, Zero, 0xff)
                    Field(ERAM, ByteAcc, NoLock, Preserve)
                    {
                                Offset (0x18),
                        SPTR,   8,
                        SSTS,   8,    // <- NHC will read/write at offset 0x19 one byte (8 Bits)
                        SADR,   8,
                    }
                }
            }
        }
    }
}

 
 
Read and write FIELD objects by offset with custom FieldFlags
 
 
The above functions ACPI.FIELD.ReadbyOffset() and ACPI.FIELD.WriteByOffset() will use the default
FieldFlags AccessType="ByteAcc", LockRule="NoLock" and UpdateRule="Preserve".
 
With the following functions it is possible to define custom FieldFlags:
 
bool ACPI.FIELD.ReadByOffset (string name, ref int value, int offset, byte dataSize, string accessType,
                                                  string lockRule, string updateRule);
 
bool ACPI.FIELD.WriteByOffset (string name, int value, int offset, byte dataSize, string accessType,
                                                  string lockRule, string updateRule);
 
The following FieldFlags are available:
 
AccessType = "AnyAcc" or "ByteAcc" or "WordAcc" or "DWordAcc" or "QWordAcc" or "BufferAcc"
LockRule = "NoLock" or "Lock"
UpdateRule = "Preserve" or "WriteAsOnes" or "WriteAsZeros"
 
(Note: EmbeddedControl and CMOS support only ByteAcc; SMBus support only BufferAcc)
 
Examples:
 
bool result = ACPI.FIELD.ReadByOffset ("_SB.PCI0.LPCB.EC0.ERAM", ref value, 0x19, 8, "ByteAcc", "Lock",
                                                           "Preserve");
 
bool result = ACPI.FIELD.WriteByOffset ("_SB.PCI0.LPCB.EC0.ERAM", 0x7D, 0x19, 8, "ByteAcc", "Lock",
                                                           "Preserve");
 
 
G o o g l e   l i n k s
 
 
CPU Voltage information and examples
 
1. CPU stability problems -> CPU voltage variation / fluctuation
 
Possible problems:
 
 
- One day the CPU is stable, another day the CPU made calculation errors and causes the system to crash (blue screen).
- With a full battery level the CPU is stable, with a low battery level CPU made calculation errors and causes the system to crash.
- If I connect a external hardware the CPU makes calculation errors and causes the system to crash. (by connecting new hardware you will have short voltage fluctuation).
 
Why do I have these CPU stability problems with this Voltage, even if the NHC CPU Stability Check program, Prim95 or Hot CPU Tester does not report problems with this voltage? The answer is CPU voltage fluctuation (variation).
 
The CPU Voltage quality is not perfect; there are always little voltage fluctuations (voltage variations). It is possible, that the mainboard on tuned 0.700V doesn't exactly tune to 0.700V (with a deviation of +-10% you get 0.630V resp. 0.770V which are +-0.070V). 0.630V is to low and the CPU will make calculation errors. If you add a safety margin of 0.100V to your Voltage the new max. and min. voltages (with a deviation of +-10%) are 0.870V / 0.730V. The min. Voltage of 0.730V is greater as 0.700V. The CPU is stable also on voltage fluctuations of +-10%.
 
It is always recommended to add a safety margin of +10% to +20% on your CPU voltage.
 
On higher CPU frequency you may should calculate a greater margin as on lower frequency.
 
Voltage example with and without safety margin:
 
Therefore, I have the following voltages on a Dothan 1600 with safety margin It works without miscalculations with lower voltages too; lacking safety margin however
06 @ 0.956V
08 @ 1.116V
10 @ 1.228V
12 @ 1.356V
14 @ 1.452V
15 @ 1.484V
06 @ 0.812V
08 @ 0.924V
10 @ 1.036V
12 @ 1.164V
14 @ 1.260V
15 @ 1.292V
 
2. CPU Voltage examples for Notebook Hardware Control
 
Dothan 725 (1,6GHz, 100MHz FSB) Format: Multiplier @ Voltage (i.e. 06 @ 0.988V)
Intel's default voltages reducing voltage by ~0.2V more voltage reducing
06 @ 0.988V
08 @ 1.068V
10 @ 1.132V
12 @ 1.212V
14 @ 1.276V
16 @ 1.340V
06 @ 0.780V
08 @ 0.860V
10 @ 0.924V
12 @ 1.004V
14 @ 1.100V
16 @ 1.196V
06 @ 0.700V
08 @ 0.812V
10 @ 0.908V
12 @ 1.004V
14 @ 1.100V
16 @ 1.196V
 
Banias 1,5GHz (100MHz FSB) Format: Multiplier @ Voltage (i.e. 06 @ 0.956V)
Intel's default voltages reducing voltage by ~0.2V more voltage reducing
06 @ 0.956V
08 @ 1.116V
10 @ 1.228V
12 @ 1.356V
14 @ 1.452V
15 @ 1.484V
06 @ 0.812V
08 @ 0.924V
10 @ 1.036V
12 @ 1.164V
14 @ 1.260V
15 @ 1.292V
06 @ 0.796V
08 @ 0.908V
10 @ 1.004V
12 @ 1.100V
14 @ 1.148V
15 @ 1.260V
 
Sonoma 730 (1,6GHz, 133MHz FSB) Format: Multiplier @ Voltage (i.e. 06 @ 0.812V)
Intel's default voltages reducing voltage by ~0.2V more voltage reducing
06 @ 0.956V
08 @ 1.116V
10 @ 1.228V
12 @ 1.356V
14 @ 1.452V
15 @ 1.484V
06 @ 0.812V
08 @ 0.924V
10 @ 1.036V
12 @ 1.164V
14 @ 1.260V
15 @ 1.292V
06 @ 0.796V
08 @ 0.908V
10 @ 1.004V
12 @ 1.100V
14 @ 1.148V
15 @ 1.260V
 
Return to top