Falcosoft wrote on 2024-03-25, 11:17:

Overall the problem seems to be that the set routines always use 'hardware' P-state numbering but the select routines use 'software' P-state numbering. In case of older Phenoms and Thuban with disabled boost there is no difference between the 2 numbering systems. But with enabled boost on Thuban there is an offset (1) between the 2 numbering systems:
software_pstates.png

Well, it's not as what you speculated. The program had implemented both software and hardware p-state numbering. It first reads the PSTATE_STATUS msr (MSRC001_0063) to find out the current software p-state number (current_pstate). Then physical msr number = (MSRC001_0064 + number_of_boost_states + current_pstate). Then it checks whether current_pstate is 0, and if so, toggle the TSC bit in HWCR msr.

kalohimal wrote on 2024-03-25, 14:26:

Falcosoft wrote on 2024-03-25, 11:17:

Overall the problem seems to be that the set routines always use 'hardware' P-state numbering but the select routines use 'software' P-state numbering. In case of older Phenoms and Thuban with disabled boost there is no difference between the 2 numbering systems. But with enabled boost on Thuban there is an offset (1) between the 2 numbering systems:
software_pstates.png

Well, it's not as what you speculated. The program had implemented both software and hardware p-state numbering. It first reads the PSTATE_STATUS msr (MSRC001_0063) to find out the current software p-state number (current_pstate). Then physical msr number = (MSRC001_0064 + number_of_boost_states + current_pstate). Then it checks whether current_pstate is 0, and if so, toggle the TSC bit in HWCR msr.

OK, but then I would like to report that it does not work on my system with enabled boost 😀
Can I give you any debug output for troubleshooting?

Please see one post above... (last post on page 12)

Screenshots from the following would be helpful:
cpuspd pa
cpuspd d p

I suspect "number_of_boost_states" might be the culprit for your cpu. If this value is 0 instead of 1 then we'll have the exact problem as you described.
This value is read from PCI config register, so perhaps family 10h and 15h has different register for this value? I'll check the docs when I have time.

kalohimal wrote on 2024-03-25, 14:32:

Please see one post above... (last post on page 12) […]
Show full quote

Please see one post above... (last post on page 12)

Screenshots from the following would be helpful:
cpuspd pa
cpuspd d p

I suspect "number_of_boost_states" might be the culprit for your cpu. If this value is 0 instead of 1 then we'll have the exact problem as you described.
This value is read from PCI config register, so perhaps family 10h and 15h has different register for this value? I'll check the docs when I have time.

OK, here is screenshot about the above command's output:

And also here is a test video about what is happening (sorry for the shaky video, it was made with a mobile phone):
https://youtu.be/vK0bTlaMFII

@EDit:
And here is the output of the commands when boost is disabled ( and everything is working perfectly):

From the screenshot, number of boost states is 0, so there is no boosted p-states, and P0 is the first physical msr. It is not one boosted p-state like you mentioned. Btw so far I've not seen any K10 family cpu where the motherboard BIOS will setup boost states...

Anyway please try again with these commands:
cpuspd pa
cpuspd d pm000422 pa

The second command will show whether changes to p0 is indeed registered, and also the debug info for cps (current p-state) and nbs (number of boost states).

kalohimal wrote on 2024-03-25, 15:17:

From the screenshot, number of boost states is 0, so there is no boosted p-states, and P0 is the first physical msr. It is not o […]
Show full quote

From the screenshot, number of boost states is 0, so there is no boosted p-states, and P0 is the first physical msr. It is not one boosted p-state like you mentioned. Btw so far I've not seen any K10 family cpu where the motherboard BIOS will setup boost states...

Anyway please try again with these commands:
cpuspd pa
cpuspd d pm000422 pa

The second command will show whether changes to p0 is indeed registered, and also the debug info for cps (current p-state) and nbs (number of boost states).

OK, here is the requested screenshot:

BTW, I have attached the screenshot of the non-boosted state to the end of my previous post (when everything is working perfectly).
So the point is that when boost is disbled in BIOS then eveything is working perfectly. When boost is enabled in BIOS then pm (f, etc.) command itself does nothing (as you can see in the video). You also have to set the required pmxxyyzz value to the higher P1 state and then you have to select the P0 state again in order changes to take effect.

Ok, the problem is as what I suspected earlier, that nbs (number of boost states) is reported as 0 when it is supposed to be 1, even when you enabled it in the BIOS.

This value is taken from PCI bus 0 device 18h function 4, register 15Ch, bit 2 (AMD 31116 Rev 3.62 - January 11, 2013, p.350). If this value is incorrect then we'll have a problem. According to AMD doc, register 15Ch is only valid for cpu revision E. Any earlier revision and this register will be "reserved", meaning it will be 0 when read.

Could you check the revision of your cpu please? Perhaps using cpuspd i. From the list of Thuban Phenom II cpus, all of them should be stepping E0, which is strange...

kalohimal wrote on 2024-03-25, 15:49:

Ok, the problem is as what I suspected earlier, that nbs (number of boost states) is reported as 0 when it is supposed to be 1, even when you enabled it in the BIOS.

This value is taken from PCI bus 0 device 18h function 4, register 15Ch, bit 2 (AMD 31116 Rev 3.62 - January 11, 2013, p.350). If this value is incorrect then we'll have a problem. According to AMD doc, register 15Ch is only valid for cpu revision E. Any earlier revision and this register will be "reserved", meaning it will be 0 when read.

Could you check the revision of your cpu please? Perhaps using cpuspd i. From the list of Thuban Phenom II cpus, all of them should be stepping E0, which is strange...

Hi,
My CPU revision is PH-E0 as reported by CPU-Z:

I have a BIOS guide for AMD Family 10h propcessors. It states that boost is enabled when (page 52):

CPB is enabled if all of the following conditions are true: • F3xA8[CacheFlushPopDownEn] = 1. • F3x188[EnStpGntOnFlushMaskWakeu […]
Show full quote

CPB is enabled if all of the following conditions are true:
• F3xA8[CacheFlushPopDownEn] = 1.
• F3x188[EnStpGntOnFlushMaskWakeup] = 1.
• F4x15C[BoostSrc] = 11b.
• F4x15C[NumBoostStates] = 1.
• F4x16C[CstateCnt] != 0h.
• MSRC001_0015[CpbDis] = 0 for all cores.

So it seems the same bits you mentioned have to be set but other condiditons also have to be met. Yet, the real world situation is that CPB is enabled (at least the CPU behaves according to the enabled state) but the bits are not set by my BIOS...

BTW, in case of my BIOS this is the only setting I change when I get the different results shown on the screenshots:

Yes, that's the doc I am referring to all along, Rev 3.62.

The BIOS had turned on CPB in the cpu, and should set the following to 1, but instead it remains as 0:
F4x15C[NumBoostStates] = 1
This is the "PCI bus 0 device 18h function 4, register 15Ch, bit 2" I was referring to previously.

So we've found a bug in the BIOS of your motherboard. Perhaps you could check whether there is any update available? Otherwise there is nothing much we could do, except to disable it in the BIOS.

kalohimal wrote on 2024-03-25, 16:24:

Yes, that's the doc I am referring to all along, Rev 3.62. […]
Show full quote

Yes, that's the doc I am referring to all along, Rev 3.62.

The BIOS had turned on CPB in the cpu, and should set the following to 1, but instead it remains as 0:
F4x15C[NumBoostStates] = 1
This is the "PCI bus 0 device 18h function 4, register 15Ch, bit 2" I was referring to previously.

So we've found a bug in the BIOS of your motherboard. Perhaps you could check whether there is any update available? Otherwise there is nothing much we could do, except to disable it in the BIOS.

So it seems the same bits you mentioned have to be set but other condiditons also have to be met. Yet, the real world situation is that CPB is enabled (at least the CPU behaves according to the enabled state) but the bits are not set by my BIOS.
The strange thing is that CPB and boosted state works perfectly in Windows when enabled in the BIOS.
This is the latest BIOS for my board and actually the only one that supports Thuban (F7D).
https://www.gigabyte.com/Motherboard/GA-MA790 … ort#support-cpu

This is just a theoretical problem anyway since I use my Phenom II without boost enabled all the time. I have just checked CPB since you explicitly mentioned it in the new version of CpuSpd.

One way I can think of to bypass this issue is to ignore F4x15C[NumBoostStates], and check for all other conditions to see whether CPB is enabled. If so then set nbs to 1, since there could only be 1 boost state for K10 cpus. But then the amount of work doesn't justify as you could simply turn it off in BIOS. It is not need in retro DOS gaming anyway.

kalohimal wrote on 2024-03-25, 16:39:

One way I can think of to bypass this issue is to ignore F4x15C[NumBoostStates], and check for all other conditions to see whether CPB is enabled. If so then set nbs to 1, since there could only be 1 boost state for K10 cpus. But then the amount of work doesn't justify as you could simply turn it off in BIOS. It is not need in retro DOS gaming anyway.

I do not think it is necessary, for me at least it's not. As you said it's not needed for DOS and for that matter even is Windows this first version of CPB is rather problematic.
It's much better to use manual clock/voltage fine tuning and P-state adjustment with the help of K10Stat.

Hi, IDK it's a good place for it but I kindly ask for further clarification about CPU throttling and CPU ODCM features. Ok, by setting 1/8 value we achieve skipping 7 of 8 sent clock signals and effectively get 1/8 CPU clock. But how it works with 7/8 value? Does it mean after 7 "normal" signals come longer interval between 7. and 9. cycles, so cycle intervals are asymmetrical?

Also, how does clock skipping affect FSB or RAM clocks?

Has anyone got any examples of cpuspd and the available slowdown settings on say a MMX CPU from anywhere in the region of 166 to 233?

Current setup is a Cyrix 5x86-120, and with the ability to drop the multiplier to 1x and disable L1 cache, it is broadly equivalent to a 386dx-40.

Can cpuspd drop an MMX CPU to an equivalent level with the various Pentium register settings?

kalohimal wrote on 2024-01-21, 07:45:

Transmeta p-state is implemented but not tested. Please note that Transmeta cpus could only change p-state but not setting them (at least that's what appeared to be in the public docs).

Can confirm the tool works on HP T5710, I've managed to run Crystal Dream 2 on that machine now without the dreaded "Runtime Error 200" patching (used the P-state 4, so 300 MHz clock)!
Epic Pinball seems a bit more playable at that speed too.

For Pentium D CPU’s like D950 or D960, what is minimum multiplier? And I wonder if there is any way to adjust FSB.

Why, when more than one core is enabled (or HT is enabled), it is no longer possible to change the multiplier to 4790K:

but when only one core is enabled, the multiplier changes correctly:

Is this the standard behavior for CPUSPD, or is there something else that needs to be configured? Thank you.

DoZator wrote on 2025-06-20, 00:34:

Why, when more than one core is enabled (or HT is enabled), it is no longer possible to change the multiplier to 4790K: […]
Show full quote

Why, when more than one core is enabled (or HT is enabled), it is no longer possible to change the multiplier to 4790K:

The attachment CPUSPD4C.PNG is no longer available

but when only one core is enabled, the multiplier changes correctly:

The attachment CPUSPD1C.PNG is no longer available

Is this the standard behavior for CPUSPD, or is there something else that needs to be configured? Thank you.

I'm not sure 4th Gen ix has been thoroughly tested so far. The main problem must be the multi-core logic of Speedstep.
Transitions to lower performance states are only possible if All cores gets the low p-state values. If only one core gets the lower p-state values in its MSR then the CPU core registers the request to the targeted operating point but the transition won't occur.
Since under DOS only the bootstrap processor is available by default, you can only set higher p-states than the values configured in the BIOS.
As the author wrote previously:

... in order to change multiplier, you need to start from low and change to high if changing only on one core. If you start from high and change to low, ALL cores need to be programmed with the new MSR value, if not, transition will not take place (this coincides with Falcosoft's findings in his comment). That in fact took a large chunk of my time when I was developing the program, as doing multiprocessor programming for DOS is not trivial.

The point is the author has written some magic to handle multi-core under DOS but it seems it is not fully working with 4rd Gen ix.
So when multi-core is enabled, you should test if you can set higher multiplier than set in the BIOS. If yes, then the problem is almost 100% sure is the same one as the above mentioned.

Falcosoft wrote on 2025-06-20, 07:14:

I'm not sure 4th Gen ix has been thoroughly tested so far. The main problem must be the multi-core logic of Speedstep. Transitio […]
Show full quote

DoZator wrote on 2025-06-20, 00:34:

Why, when more than one core is enabled (or HT is enabled), it is no longer possible to change the multiplier to 4790K: […]
Show full quote

Why, when more than one core is enabled (or HT is enabled), it is no longer possible to change the multiplier to 4790K:

The attachment CPUSPD4C.PNG is no longer available

but when only one core is enabled, the multiplier changes correctly:

The attachment CPUSPD1C.PNG is no longer available

Is this the standard behavior for CPUSPD, or is there something else that needs to be configured? Thank you.

I'm not sure 4th Gen ix has been thoroughly tested so far. The main problem must be the multi-core logic of Speedstep.
Transitions to lower performance states are only possible if All cores gets the low p-state values. If only one core gets the lower p-state values in its MSR then the CPU core registers the request to the targeted operating point but the transition won't occur.
Since under DOS only the bootstrap processor is available by default, you can only set higher p-states than the values configured in the BIOS.
As the author wrote previously:

... in order to change multiplier, you need to start from low and change to high if changing only on one core. If you start from high and change to low, ALL cores need to be programmed with the new MSR value, if not, transition will not take place (this coincides with Falcosoft's findings in his comment). That in fact took a large chunk of my time when I was developing the program, as doing multiprocessor programming for DOS is not trivial.

The point is the author has written some magic to handle multi-core under DOS but it seems it is not fully working with 4rd Gen ix.
So when multi-core is enabled, you should test if you can set higher multiplier than set in the BIOS. If yes, then the problem is almost 100% sure is the same one as the above mentioned.

Thanks for the detailed explanation and tip. It really worked! I set the multiplier to "8" in the BIOS and added "CPUSPD m40" to the very beginning of AUTOEXEC.BAT. Now, Windows starts with a multiplier of "40" and allows me to change it to any value between "8" and "40", even in a multi-core configuration (with HT enabled):

In general, everything works correctly under Windows 98 and MS-DOS.

All that's left is to figure out a way to reset the multiplier to "40" under Windows XP (installed on the same PC, on a separate partition). CrystalCPUID, in principle, allows you to change the multiplier on a given processor (using the /Fxx parameter), but it hasn't been updated for a while, and it doesn't seem to fully support the 4th generation. It has some internal limitations that prevent the multiplier from exceeding a certain value (based on my rough estimates based on benchmarks, it's around "31"), even if you use the "/F99" parameter (which should theoretically increase the multiplier to its maximum allowed value). Unfortunately, I haven't found any other XP-compatible tools (CPUSPD doesn't officially support XP).

I just wish it better supported gen7.

I have an older NUC (7th gen i5, iirc) that works with vsbhda(sf), that would be nice to make into a retrostation, but the thing becomes very cranky/unstable when I use cpuspd on it to slow it down.

I'll just continue being patient. 😀