Zitat von daniel_k im Beitrag #1786 By the way, how much RAM available does XP x64 shows in System Properties? For some reason, here it shows only 15.9GB instead of the full 16.0 GB RAM.
check with any e820 tool ram ranges, if is it 15.9 - bios claimed some ram
Can't patch this without moving down some instructions like mov rdi,[r15][0000198E0] which obviously has relocation.
You shift code, this is not i like, in this case i prefer more generic way (but more complex and need some knowledge of mapping segment) 1) extend code segment to max available (max is begin of next segment - 1 byte) in PE header 2) look in reloc table about possible reloc in calling memcpy_s (ff 15 76 1f 01 00 is call qword PTR [rip+0x11f76] , so it is IP relative call and no need reloc) 3a) if no reloc replace CALL memcpy_s to CALL newcode to new code placed at end of segment or 3b) replace CALL memcpy_s to JMP newcode to new code placed at end of segment 4) add new commands with any lengh (but dont use absolute adressing, otherwise you need patch reloc table)
1 2 3 4 5 6 7 8 9 10
newcode: XX XX XX mov rdx, r8 (new *src <- old *src, 64b) XX XX XX mov r8d,r9d (new count <- old count, 32b) FF 15 XX XX XX XX call memcpy (your assembler must calculate offset between current ip and memcpy) 3a: XX XX XX ret 3b: XX XX XX jmp 791EA
Zitat von daniel_k im Beitrag #1763 About the intelppm.sys, doesn't it have the same effect as setting the XP's power scheme to Portable/Laptop? I've been doing this for years, that's the only way to make C1E to work on a desktop.
Zitat von diderius6 im Beitrag #1755the powermanagment is corrupt on all Intel boards from Skylake above.
Now i think some acpi hardware functionality is disabled by bios vendors for some reason (recomendation from intel ?) This functionality is not used anymore in WIN 7+, so nobody cares
Zitat von diderius6 im Beitrag #1643 With cristaldiskinfo I can see, that TRIM is supported but I do not know, how to test under XP, if TRIM works.
same as for win7 - trimcheck to force generate trim command to drive i used in past TxBENCH (manual with GUI) and O&O Defrag in CLI mode (scheduled at booting time of winxp)
Zitat von diderius6 im Beitrag #1455 Another idea would be: The DSDT table can be seen in (ACPI only) XP registry and also been edited there. But on next boot the Bios loads its original own DSDT. If we just can stop writing of Bios its own DSDT to the registry again, it would be done
I feel that it is time to remind about my util called "acpi patcher" ) it is dsdt/ssdt table manipulation tool before OS loading, even for winxp textmode setup
Zitat von diderius6 im Beitrag #765 *** Assertion failed: PciInterfacesInstantiated *** Source File: d:\xpsp\base\busdrv\acpi\driver\nt\irqarb.c, line 3512
proper init PciInterfacesInstantiated variable is in AcpiArbInitializePciRouting() AcpiArbInitializePciRouting() do IRP request to self (i mean acpi.sys) some handler inside acpi.sys do jobs with this request and return "not zero" not zero mean variable still be zero and we skip calling magic "call dword ptr [esi+8]"
Zitat von diderius6 im Beitrag #732 Here if APIC mode, then set DBG8 = 0xAA and for PIC mode DBG8 = 0xAC. This variable DBG8 is not used in DSDT table, but seems to be needed at other place.
DBG8 is I/O Port 80 (port for POST codes from ancient times), you can skip any operations with it
ZitatWhen (from an unknown place set) Arg0=1, then APIC mode is enabled in DSDT, all devices use APIC. Is Arg0=0 then the devices in DSDT table all use PIC mode. This simple means, even without any ACPI, the DSDT and SSDT tables have to be read for to decide APIC or PIC mode. This information is in Arg0.
see apci spec, method _pic() called by OS to inform bios about needed pic mode. i think method called by HAL.dll, because we have variation of it (pic, apic, apci+apic, mp+*, ...) in your case if xp want apic, first call _pic(1), then call DSPI(), NAPE() dspi does some magic with 0x0c00 port (amd specific port ?)
Zitat von diderius6 im Beitrag #712 PS: What I do not understand is the difference between DSDT and SSDT tables. acpi.sys reads only DSDT. But from yesterday I know, that not only acpi.sys is reading DSDT, strange enough. Who reads the other tables?
mssmbios reads ssdt, facp and other nvidia driver reads ssdt
Zitat von diderius6 im Beitrag #708 I use the DSDT from the SABERTOOTH-990FX-R20-ASUS-2901. It is a AM3+ XP friendly board. In the DSDT the Hpet is handled correct and there are no Externals at all. This DSDT I flash to Bios from Asrock B350 board.
- dsdt is not very portable on modern plarforms because uses hardcoded mem ranges, bios fill memory with values, windows read acpi code and read these memory, this is communication os<->bios. For portability need similar platform/chipset. - dsdt (body.bin) from bios filesystem is template (on intel platform), final state produced by bios before os loading example of template in dsdt:
ZitatName (PNVB, 0xFFFF0000) Name (PNVL, 0xAA55)
final state:
ZitatName (PNVB, 0xCEF8D018) - dynamic adress filled by bios Name (PNVL, 0x022E)
Win-Raid Forum (Drivers - Firmware - Modding) » Search for Mov AX, 0xDEAD's content 
Tue Aug 20, 2019 6:13 pm