Version 2.1 released. Please download from post #1.

What's new:

1. Bug fixes for VIA C3 D-cache control commands.
2. Added p-states control for AMD K10 cpus (Athlon II, Phenom II, etc).

Note:
Commands moved:
For D-cache: cdd/cde => ecd/ece
For I-cache: cid/cie => eid/eie

How to use p-state controls:

P-states are the power saving states of the CPU. The higher the p-state the lower the power.
So for a CPU with 4 states:
P0 (most power/fastest) --> P3 (least power/slowest)
For AMD K10 cpu you could modify the Fid, Did, and Vid of a p-state.

P-state commands:
p[x] - display CPU p-state if run without any parameters, or switch current p-state to x, where x is 0-7 in decimal.
pa - list all p-states set up by BIOS.
pm[ffddvv] - set current CPU p-state value to ffddvv in hex for AMD (must be 6 digits).

Where,
ff = FID value in hex (00-3F) - Freq ID: PLL frequency multiplier relative to reference clock (6-bit).
dd = DID value in hex (00-04) - Divisor ID: post-PLL divisor to reduce the operating frequency. 00 = divide by 1, 01 = divide by 2, 02 = divide by 4, 03 =divide by 8, 04 = divide by 16
vv = VID value in hex (00-FF) - Voltage ID: voltage level (please see formula below).
For AMD, the value for the pm command must be 6 digits.

CPU voltage is calculated with this formula:
If VID >= 20h, voltage = 0.7625V - 0.0125V * (VID-20h);
else voltage = 1.550V - 0.025V * VID;

For example:
CPUSPD i p (display current p-state, it defaults to P0 when booted up)
CPUSPD p3 (switch current p-sate to P3)
CPUSPD pm00040c (edit current p-state, P3, to FID=0, DID=04, VID=0C)

To revert back to original speed is very easy, you just switch back to P0. To slow down again, switch to P3 (or whichever p-state of your choice).
CPUSPD p0 (revert to original speed)
CPUSPD p3 (slow down again)

Please note that TSC is tied to p-state 0 by hardware. So if your games/apps need accurate TSC, please use p-state 0.

It looks like AMD K10 is a very good platform for retro DOS gaming. These CPUs can be slowed down enough to 486 speed just by manipulating their multiplier and divisor and south bridge throttling becomes unnecessary. To slow down further, cache could be turned off to achieve 286 speed and slower.

Test hardwares:
Biostar N68S3+ v6 with: Athlon II X2 250, Athlon II X2 440, Athlon II X4 600e, Athlon II X4 640.
Gigabyte GA-770T-D3L with Athlon II X2 440.

Settings for Wing Commander 1 (about 486-133):
cpuspd pm0504xx
xx is vid and is CPU dependent. You could use "cpuspd pa" to list all the p-states set up by BIOS. You don't need to change the vid and could stick to the vid value in p-state 0. Read the datasheet for your CPU to find out the voltage range if you would like to lower it.
Sound: SBEMU - working
Game controls: keyboard - working

Settings for Alley Cat (about 286 level):
cpuspd pm0902xx cd
xx is as above. Please note that we've disabled cache here.
Sound: PC speaker - working
Game controls: keyboard - working

kalohimal wrote on 2024-02-08, 14:23:

It looks like AMD K10 is a very good platform for retro DOS gaming. These CPUs can be slowed down enough to 486 speed just by manipulating their multiplier and divisor and south bridge throttling becomes unnecessary. To slow down further, cache could be turned off to achieve 286 speed and slower.

Yep, I can confirm this.

Slowing down AMD K10 (Phenom and Phenom II) to 486's speed... but how is this possible? Is it necessary to disable all cores of the CPU except one or there is no such need, because DOS programs are always executed and run on one core?

analog_programmer wrote on 2024-02-08, 20:22:

Slowing down AMD K10 (Phenom and Phenom II) to 486's speed... but how is this possible? Is it necessary to disable all cores of the CPU except one or there is no such need, because DOS programs are always executed and run on one core?

No, you do not have to disable any cores explicitly. Under DOS only the bootstrap processor (CPU 0) is used anyway. In case of K10 the big plus compared to other CPUs is the extremely flexible FID/DID system. Supposing normal 200 MHz bus speed the CPU core can be set as low as 100 MHz. And with 16-bit code the K10 is not particularly fast at 100 MHz (it is mostly slower than a Pentium clock for clock) so it does not even trigger the infamous Borland division by zero bug or some speed sensitive software quirks that happened around the 200 MHz barrier. Also you can set the core clock from 100 Mhz by 6.25 MHz steps (Bus clock / 2 / 16).
Another unique and interesting feature of the K10 is that you can reset the TSC clock to the actual P-state 0 clock (after you change P-state 0).

Falcosoft wrote on 2024-02-08, 22:13:

No, you do not have to disable any cores explicitly. Under DOS only the bootsrap processor (CPU 0) is used anyway. In case of K10 the big plus compared to other CPUs is the extremely flexible FID/DID system. Supposing normal 200 MHz bus speed the CPU core can be set as low as 100 MHz. And with 16-bit code the K10 is not particularly fast at 100 MHz (it is mostly slower than a Pentium clock for clock) so it does not even trigger the infamous Borland division by zero bug or some speed sensitive software quirks that happened around the 200 MHz barrier.
Another unique and interesting feature of the K10 is that you can reset the TSC clock to the actual P-state 0 clock (after you change P-state 0).

Wow! Thanks for this info, I didn't knew about this AMD K10 CPU capabilities. I know about CPU's C-states, P-states, etc. CPU energy saving settings, but have no idea what is "TSC clock". Could you briefly explain what is relation between this TSC clock and P-states of the CPU and what exactly are they can be used for?

And by the way, I'm still using one Phenom II x6 T1055 (Thuban core, 95 W version) on s. AM2+ mobo as my daily driver desktop system 😀

analog_programmer wrote on 2024-02-08, 22:36:

Could you briefly explain what is relation between this TSC clock and P-states of the CPU and what exactly are they can be used for?

And by the way, I'm still using one Phenom II x6 T1055 (Thuban core, 95 W version) on s. AM2+ mobo as my daily driver desktop system 😀

The TSC is the Time Stamp Counter, a 64-bit counter introduced with the Pentium and it provides a uniform way to measure real CPU clock speed. The TSC is increased by 1 at every cpu clock. Since it provides an easy and uniform way to get an extremely high resolution and accurate clock source many software and OS used/uses it as base for timers, query real CPU speed etc.
Most modern processors have an invariant TSC so power saving features (downclock, throttling, etc.) as well as multiple cores with different clock speeds cannot influence the accuracy of TSC based timers on modern operating systems. But this way you cannot tell the real cpu clock speed on modern systems by querying the TSC anymore. On most modern CPUs the TSC clock is set at boot time and never can be changed. On K10 there is a non-documented feature (changing the TSC clock source to North Bridge clock and then back to CPU core clock) that enables the TSC clock to be synced to the real CPU core clock whenever you want. This way DOS software can identify your K10 as a real 100 Mhz CPU 😀

PS:
If you missed the edit of my previous post: you can increase the the clock speed of your K10 from 100 MHz by 6.25 Mhz steps. I do not know any other CPU modells before the K10 that enable you such fine steps.

Falcosoft wrote on 2024-02-08, 22:56:

The TSC is the Time Stamp Counter, a 64-bit counter introduced with the Pentium and it provides a uniform way to measure real CPU clock speed. The TSC increased by 1 at every cpu clock. Since it provides an easy and uniform way to get an extremely high resolution and accurate clock many software and OS used/uses it as base for timers, query real CPU speed etc.
Most modern processors have an invariant TSC so power saving features (downclock, throttling, etc.) as well as multiple cores with different clock speeds cannot influence the accuracy of TSC based timers on modern operating systems. But this way you cannot tell the real cpu clock speed on modern systems by querying the TSC anymore. On most modern CPUs the TSC clock is set at boot time and never can be changed. On K10 there is a non-documented feature (changing the TSC clock source to North Bridge clock and then back to CPU core clock) that enables the TSC clock to be synced to the real CPU core clock whenever you want. This way DOS software can identify your K10 as a real 100 Mhz CPU 😀

Ok, as far as I understand now, there are two (or more) types for this TSC clock or "tick-counter" in different CPU generations and models (for older Pentium class CPUs and for newer/modern) and the one of AMD K10-family can be tricked to act as in the older processors, right? Thus on these not so old K10 processors, as you're using P-states to set some lower CPU frequency, you also need to (re)set the TSC clock, so the hardware can be presented to the software as real old and slow CPU, right?

analog_programmer wrote on 2024-02-08, 23:16:

Falcosoft wrote on 2024-02-08, 22:56:

The TSC is the Time Stamp Counter, a 64-bit counter introduced with the Pentium and it provides a uniform way to measure real CPU clock speed. The TSC increased by 1 at every cpu clock. Since it provides an easy and uniform way to get an extremely high resolution and accurate clock many software and OS used/uses it as base for timers, query real CPU speed etc.
Most modern processors have an invariant TSC so power saving features (downclock, throttling, etc.) as well as multiple cores with different clock speeds cannot influence the accuracy of TSC based timers on modern operating systems. But this way you cannot tell the real cpu clock speed on modern systems by querying the TSC anymore. On most modern CPUs the TSC clock is set at boot time and never can be changed. On K10 there is a non-documented feature (changing the TSC clock source to North Bridge clock and then back to CPU core clock) that enables the TSC clock to be synced to the real CPU core clock whenever you want. This way DOS software can identify your K10 as a real 100 Mhz CPU 😀

Ok, as far as I understand now, there are two (or more) types for this TSC clock or "tick-counter" in different CPU generations and models (for older Pentium class CPUs and for newer/modern) and the one of AMD K10-family can be tricked to act as in the older processors, right? Thus on these not so old K10 processors, as you're using P-states to set some lower CPU frequency, you also need to (re)set the TSC clock, so the hardware can be presented to the software as real old and slow CPU, right?

Yep, exactly.

Falcosoft wrote on 2024-02-08, 23:18:

Yep, exactly.

Thank you for the explanations! Now I have to try this CpuSpd tool on my desktop Phenom II PC 😀 Is it compatible with windows console (I'm still on Win7 x64 as a second OS) or it needs pure DOS?

analog_programmer wrote on 2024-02-08, 23:41:

Falcosoft wrote on 2024-02-08, 23:18:

Yep, exactly.

Thank you for the explanations! Now I have to try this CpuSpd tool on my desktop Phenom II PC 😀 Is it compatible with windows console (I'm still on Win7 x64 as a second OS) or it needs pure DOS?

Yes everything Falcosoft said. In addition, to program p-state in DOS for K10, the p-state MSRs in all cores are needed to be changed in order for a transition to occur (which is similar to Intel's Core 2 cpus). So what cpuspd needs to do is setup a small code fragment to program these MSRs in conventional 640k DOS memory, then ask each core to run that. If you're interested, you can take a look at the source codes posted.

Erm no, you won't be able to run cpuspd in the Win7 command console, due to the OS' strict control on ring 0 (starting from Win NT, a device driver is needed for that.) It will run in pure DOS and Win98/95 command console though, and the easiest way is to set up a flash drive to boot to DOS, and put all your DOS games/utils on it.

Please also note that PS/2 keyboard & mouse will be better than the USB version, because for USB keyboard/mouse the BIOS will need to process the USB packets, and might cause sluggishness when the CPU is slowed down.

Cheers and have fun.

kalohimal wrote on 2024-02-09, 03:33:

Yes everything Falcosoft said. In addition, to program p-state in DOS for K10, the p-state MSRs in all cores are needed to be changed in order for a transition to occur (which is similar to Intel's Core 2 cpus). So what cpuspd needs to do is setup a small code fragment to program these MSRs in conventional 640k DOS memory, then ask each core to run that.

Thank you for the explanation and this interesting tool, but how CpuSpd can run on two or more cores (to set P-states of each CPU core) in DOS, since it's only pure DOS compatible and DOS does not use more than one core of the multi-core CPUs? Maybe I've missed something here... May you give some example how to achieve this: "cpuspd needs to do is setup a small code fragment to program these MSRs in conventional 640k DOS memory, then ask each core to run that"?

@analog_programmer

It's rather hard to explain without getting too deep into technical stuffs. Basically when all x86-64 cpus boot up, they start in "real mode" to be backward compatible (in real mode the conventional memory is 640k). That's the reason why DOS could still run on modern cpus. During this time the bootstrap processor (BSP) is started and DOS is running on it. The rest of the cores (called application processors, AP) are put in a halt state. When modern OSes runs, they all starts in real mode, and then switch to "protected mode", where they will have access to all available memories.

Please bear in mind that DOS is "Disk Operating System", and its purpose is to provide disk access. Of course under DOS, the BIOS/DOS also provides interrupt calls for common functions like reading the keyboard or putting text on screen. So if you use DOS calls provided by the BIOS/DOS then your programs runs in real mode on the BSP. But that doesn't mean you are not allowed to access the rest of the hardware inside the CPU, like the APs. There is a facility provided in the CPU called APIC (Advanced Programmable Interrupt Controller), which allow a program to trigger and start an AP, besides providing interrupt services. Of course before an AP is started, initialization needs to be done, like setting up the start executing address, etc. And so that's how CPUSPD could ask the rest of the cores to execute - by setting up the execution address, insert an interrupt to APIC to trigger the required AP, and have it run the program loaded in memory. Once done the AP returns to a halt state. This method is in fact how programs like Memtest and modern OS like Windows and Linux starts a new process on any CPU core. So CPUSPD is in essence, a DOS program that could do SMP (Symmetric multiprogramming), although only in a very small scale.

kalohimal wrote on 2024-02-09, 03:33:

Yes everything Falcosoft said. In addition, to program p-state in DOS for K10, the p-state MSRs in all cores are needed to be changed in order for a transition to occur (which is similar to Intel's Core 2 cpus). So what cpuspd needs to do is setup a small code fragment to program these MSRs in conventional 640k DOS memory, then ask each core to run that. If you're interested, you can take a look at the source codes posted.
....

Hi,
I must correct you this time since this is not true. Do you remember this proof of concept (K10Min) that I wrote?
Re: CpuSpd - A Hardware Based CPU Speed Control Utility for DOS/Win98 Retro Gaming
This simple Pascal program could/can set 100 MHz under DOS with only programming P0 state on bootstrap CPU. And since in DOS only the bootsrap CPU is available it works.
So contrary to Intel you can set P-sates and FID/DID values independently on each core on K10. This is also true on Windows anyway: in case of multi-core aware OSes you can have cores set to completely different P-states and core clocks.

Thanks for this detailed explanation, kalohimal! For me this is enough:

kalohimal wrote on 2024-02-09, 08:35:

And so that's how CPUSPD could ask the rest of the cores to execute - by setting up the execution address, insert an interrupt to APIC to trigger the required AP, and have it run the program loaded in memory. Once done the AP returns to a halt state.

But it's nice that you gave more of the details here 😀

kalohimal wrote on 2024-02-09, 03:33:

Yes everything Falcosoft said. In addition, to program p-state in DOS for K10, the p-state MSRs in all cores are needed to be changed in order for a transition to occur (which is similar to Intel's Core 2 cpus). So what cpuspd needs to do is setup a small code fragment to program these MSRs in conventional 640k DOS memory, then ask each core to run that. If you're interested, you can take a look at the source codes posted.
....

To be more precise:
You can set P-states and FID/DID values only on the bootstrap CPU and it works under DOS, the transition occurs properly. The process you described is only needed for VID/voltage transitions (that is all cores have to be set to a lower voltage otherwise the highest voltage set on a CPU core wins).
But this does not change the fact that contrary to Intel you can set P-states and FID/DID values independently on each core on K10. Not all cores are needed to be changed, and not all CPU core MSRs have to be set to the same value in order per core transitions to work.
This is true even on multi-core aware operating systems:

So overall in this regard K10 is very different from Intel's Core 2 (where you have to set all core MSRs in order FID/CPU speed transitions to occur).

Hmm ok, perhaps I remember wrongly. Two years ago I've added code to the SMP AP to perform fid did vid switch to all cores. I couldn't recall why but perhaps it's the vid like you said. Come to think of it there is no reason why different cores cannot have different multiplier and divisor, so yeah you're probably right.

Ok today I found some time to re-look at the "AMD Family 10h Processor BKDG Rev 3.62" public document. The following is taken from page 52, under section "2.4.2 P-states":

In the doc it said, "All FID and DID parameters must be programmed to equivalent values for all cores and NBs in the coherent fabric." So in order to change the FID VID values for a particular p-state on a core, all corresponding FID VID values for that p-state must be changed on all other cores as well. Of course you could have different p-state selected for each core, but the p-state definition must be the same for each p-state across all cores.

As I recalled, I'd initially experimented with setting p-state on only one core, and it wasn't working. So I added codes to the smpap.asm module to make the changes to all cores.

kalohimal wrote on 2024-02-12, 17:09:

Ok today I found some time to re-look at the "AMD Family 10h Processor BKDG Rev 3.62" public document. The following is taken fr […]
Show full quote

Ok today I found some time to re-look at the "AMD Family 10h Processor BKDG Rev 3.62" public document. The following is taken from page 52, under section "2.4.2 P-states":

amd_k10_1.jpg

In the doc it said, "All FID and DID parameters must be programmed to equivalent values for all cores and NBs in the coherent fabric." So in order to change the FID VID values for a particular p-state on a core, all corresponding FID VID values for that p-state must be changed on all other cores as well. Of course you could have different p-state selected for each core, but the p-state definition must be the same for each p-state across all cores.

As I recalled, I'd initially experimented with setting p-state on only one core, and it wasn't working. So I added codes to the smpap.asm module to make the changes to all cores.

The theory and practice can differ the same way as in case of TSC reset: it also works despite the fact that the documentation says otherwise.
I have also tried with different K10 versions and revisions and setting different p-states on different cores works on all. Please , check again. As a quick confirm/refute test you can run my old test program under DOS (K10Min).
As you will see it works and can set 100 Mhz core clock without problems despite the fact that it only sets the p-state (and modifies FID/DID) on the bootstrap processor (CPU 0):
download/file.php?id=87832

BTW, even if this was true and only different p-states could be set on cores but the FID/DID values had to be set the same way on each core, that still would not make the K10 behavior similar to Intel's Core 2. In case of Core 2 you cannot have different frequencies on the diferent cores so you have to program all to the exact same frequency (there is no similar concept to per core p-states). You cannot set different core clocks under DOS by programming only the bootstrap core and you also have to program the AP cores. In case of K10 this is not the case: you can set a different core frequency by simply setting a different p-state on the bootsrap core even without touching AP cores (or FID/DID values explicitly).

Fair enough and thanks for sharing. But unfortunately I simply do not have the time nor interest to dwell on this further. As already mentioned I've previously experimented and found changing the BSP alone won't do the trick, at least not on the CPU I tested. I'd rather stick with what AMD docs said, than depending on undocumented functions that might not work across all CPU revisions, and have people coming with issues and creating lots of headaches that need fixing later. Good day and have fun.