@diderius6
Just as a matter of record can you describe in detail what exactly is the hal timer problem?
what is the cause of it?
what are the symptoms of the problem?
what function or functions in halmacpi.dll needs to be modified to fix it?
@infuscomus
Beginning with the Intel chipset Skylake, they implemented in each board an hardware error in the PM timer.
Together with @Mov_AX_0xDEAD I found out, that this is true on any newer board from Intel.
A closer look at Win7… shows the same error.
So, the idea was easy, to go back to the old hardware clock.
This can be proven in many ways: You can change Bios to disable the PM timer, hard job if this is not in the list of that Bios.
I make a try to fake hal.dll, just to make XP think, that the PM timer is loaded but in real it was the old hardware clock.
This gives the way free to hack hal.dll. This you can see with an hexeditor, only 2 Bytes are changed.
In the loong xp32 thread here take a look at page 12, where @Mov_AX_0xDEAD wrote about ways to overcomes this timer
error on all newer Intel boards
Dietmar
PS: The sleeping states are also broken on all newer Intel boards, beginning with Skylake.
This was a hard job even for @Mov_AX_0xDEAD to solve this problem via software, intelppm.sys.
@diderius6
can you go into detail on which function and instruction needs to be changed in halmacpi.dll for timer to work properly?
for those who have a disassembler and want to know what was changed
I was looking at original and modified hal in Flexhex for comparison and found too many differences to see what exactly was changed.
@infuscomus
I simply take an hal.dll, which uses only the old hardware clock.
Because I noticed, that in all languages all hal.dll are the same.
Then I compare this hal.dll (I think it was from XP SP2) with newer ones
from XP SP3. And I just look, what was different. In the end I came to this 2 bytes.
It is a hack on assembler, knows nothing about function or higher language
Dietmar
@diderius6
which 2 bytes in hal.dll did you change for the fix?
how did you know which bytes needed changing? was it just comparing the difference between SP0 HAL and SP3 HAL?
140: 2C => 9D
7B40: C7 => C3
@diderius6
OK
So offset 140 is the checksum - correct?
and 7B40 is HalpSetPmTimerFunction which is changed from
HalpSetPmTimerFunction:
mov dword ptr [data_0xD544], va_ptr HalpPmTimerCalibratePerfCount
mov dword ptr [data_0xD548], va_ptr HalpPmTimerQueryPerfCount
mov dword ptr [data_0xD540], va_ptr HalpPmTimerStallExecProc
ret
to just
HalpSetPmTimerFunction:
ret
correct?
@infuscomus
Hihi, I think yes. I never look at those functions,
just compare with hal.dll which uses old clock.
For me an new interesting project in XP SP3
would be, to boot XP from from a GPT drive,
because my HD with 2 Tbyte is nearly full now.
There exist the Paragon driver for XP SP3,
I have.
Also I think that Server 2003 32 bit can recognice and read/write to an GPT disk,
but cannot boot from GPT. I think, this is a missing bootfunction driver in Bios for legacy boot from GPT.
But anyway, the S4e method should to boot a harddisk with XP SP3 on it, because it offers later the needed GPT driver
during normal boot via MBR
Dietmar
PS: Would be nice, to have @daniel_k and @Mov_AX_0xDEAD for this with us, also the shorthorn author @skullteria
When it is not possible here, we can go to the forum of my digital life. I found @daniel_k there but no activities.
I’m still uncertain what exactly the old hardware timer does and how SkyLake’s new timer has changed.
How does this affect a program from running correctly?
Can you explain certain games or 3D graphics program what error would be noticed if not using the modified halmacpi.dll to use the old timer?
Also are you familiar with HDCP and does the hardware timer affect this copy protection for HDMI from working properly?
I have an idea we can test.
So Dietmar / Diderius6,
If halmacpi.dll is the only file needed to be modified to fix the timer issue . Then we should use Windows 2000 Datacenter Server SP0, SP1, SP2, SP3, and SP4 files for applying the same patch which will all work for any later NT5.X versions.
All earlier Windows 2000 files have forward compatibility with XP, 2003, and 2009. This was proven in my testing the ACPI files from Windows 2000 and swapping them in XP, 2003, and 2009 with no issues. This means if using Windows 2000 files and patching it can make all later versions work properly.
In my tests Windows 2000 Advanced Server is very stable and faster than XP on the same system. Has multicore and support for at least 32GB of RAM which XP lacked and runs most XP programs better than Server 2003 assuming the dependencies are not leaning toward XP SP3 it may even run faster.
Some may argue why waste time on Windows 2000, but I find 2000 to be more efficient and faster than XP. Now that it’s 20 years old it could use some new life. If it weren’t for the later XP dependencies added Windows 2000 would have been the best operating system made by Microsoft.
In addition, @Mov_AX_0xDEAD 's intelppm.sys seems quite useful if this file controls the power states and keeps idling cores from being > %1 or active when it should not be and wasting power. This intelppm.sys should be patched for Windows 2000 Datacenter Server as well.
What is the process for patching the intelppm.sys and I will look into testing this on W2KDCS?
At the moment I use HxD HexEditor. If you can explain how we perform this patch for both halmacpi.dl and intelppm.sys I will attempt to see if this works on Windows 2000 DCS.
From what it sounds like any system SkyLake or later requires both of these two files patched for the OS in order for the multicore CPU to function at optimal power efficiency.
I think this is tricky to overcome. GPT does not like XP for one and going GPT you break legacy compatibility with older OS. And trying to combine MBR with GPT on the same drive can have disastrous consequences . A better solution may be modifying the BIOS itself to support 4KB sector size rather than 512 Bytes only that way it can understand drives up to 16TiB and boot off of it. If this method can be perfected and a guide shown how to modify your own BIOS in the same manner then this will certainly be a tremendous boost for MBR and legacy OS users.
The issue is the 512 Byte limit per sector. If you can modify the BIOS to read in 4KB sector segments you can get rid of that 2TB hard drive and swap it for a 16TB and boot off of it.
The only other way is to modify the Windows OS system files which I do not know how much work is required to do this. You have to be able to have some software recognize whether the drive is using 512 Bytes or 4KB Bytes per sector. If you cannot recognize it in the early boot process to differentiate between the two then you will have problems. Since this method relies on patching the OS you will have to do it for any older OS that cannot understand 4K sectors.
The problem with Vista and later OS is they still treat drives as 512 Bytes per sector and use GPT to exceed the 2.0TiB limitation which is why when placing this drive into an XP system it cannot boot off this drive being larger than 2.2TB or 2.0TiB. The BIOS always assumes 512 Bytes per sector and hits the MBR Limit in 2K/XP and older OS.
So the easy fix is if there is one would be to modify a BIOS to identify if a drive is > 2.0TB to treat it as 4K sector size. If a drive is < 2.0TiB to treat as 512 Byte sector size. Then add a layer of 4K sector -> 512 Bytes sector translation so it will be transparent to any operating system and will think the drive is a true 512 Bytes drive and not care that it is actually > 2.0TiB.
If this can also be patched in the Boot Loader and Windows OS files to do this 4K -> 512 Bytes sector translation when necessary we can then boot off larger than 2.0TB drives internally or even externally via USB method. But this should also mean you should never use any hard drives < 2.0TiB that is 4Kn drive in case this will cause unexpected problems or make the drive possibly 1/8 its capacity. This is speculation as it may not matter. But most drives that are 4Kn are usually not < 2.0TiB so this might not be an issue and most will use legacy 512 Byte sector drives of 2.0TiB or less.
Again this is all theoretical at this point. You need someone who understands how to program and modify the BIOS (easiest approach) or knows enough about Windows drivers to perform this sector translation modification. It may require someone experienced in both skill sets to complete the task.
Please make a similar patch for the hal.dll (latest version 5.1.2600.5687).
https://www.upload.ee/files/11504448/hal.dll.html
Thanks. I tested this file.
With this file, in 50 % Windows does not load, but falls with BSOD. But in the other 50%, the system still works. See screenshots.
Not 2 bytes are patched (140: 2C => 9D and 7B40: C7 => C3), but much more. Changed approximately 20 bytes. It is right?
@YuriyCN
post #14 was a daniel_k modded hal that i still have
this one attached I just modded myself from the hal you uploaded
halmacpi.7z.zip (45.4 KB)
Thanks! It is perfectly!
Windows starting stably with your file.
I compared the files, but why are there so many differences.
Earlier in the topic they wrote that it is enough to fix 2 bytes.
There is one problem.
GS_Caber stopped running with the patched file.
Although all other programs work fine.
Probably GS_Caber uses a timer non-standard?
With original hal.dll:
With patched hal.dll:
All files in the Files.zip - 500 KB, includes:
GS_Сaber_1.1.5.7
hal_orig.dll - original file
hal_mod.dll - your modification
https://www.upload.ee/files/11508670/Files.zip.html
It does not depend on the intelppm.sys.
The problem appears when replacing the hal.dll only.
Why are there so many patched bytes, maybe you will make a patch hal.dll
to a minimum (with a correction of 2 bytes only)?