Wish there was something for XP...

You can use CrystalCPUID in XP.

I think i have discovered a bug.

Test System is:
Asus A8V8X-MX (Via KM400 / VT8235)
CPU: AMD Mobile Athlon 4 1600+ (1.4Ghz) AHM1600AQQ3B
OS: Direct Boot into MS-DOS 7.1

The problem in question is that VID cannot be set directly, i want it to be set at correct speed/voltage on boot so i use "cpuspd f1610" to set the CPU at 14x and 1,45v, but only the multiplier gets adjusted, the vid remains unchanged.

If i use setmul to change the multiplier then, after that, i can use CpuSpd to adjust vid correctly, it seems Setmul is enabling some register that allow CpuSpd to adjust vid on this CPU/motherboard.

EDIT: I tried another Mainboard, the MSI KT4M MS-6596 Ver. 400 (Via KT400 / VT8235), and it works as it should, i can change the VID right after reboot without issues.

Yes, I've made the same observation on my socket-A XP motherboards (Asus A7V600-X, Epox EP-8KMM3I) during testing too. It is not a program bug but the issue of whether the motherboard supports the mobile CPUs (Mobile Athlon 4, XP-M, mobile Duron, Geode NX etc.) The desktop socket-A motherboards during that era were not designed to support mobile CPUs, their CPU VRMs couldn't be lowered to the Vcore needed by the mobile CPU, so they are stuck at the minimum Vcore that the motherboard could support. Adding to this complication is that the VID coding of the socket-A mobile CPU is different from that of the desktop CPU (fab51 website has very detailed info on this issue). Only some motherboards have the proper hardware for mobile CPUs support; for those that didn't, the CPU could request the desired Vcore via the VID pins but the motherboard just couldn't do it.

One thing that is curious though is you mentioned the Vcore could be lowered after using setmul. I'm puzzled and will take a look again.

kalohimal wrote on 2020-09-09, 03:49:

Yes, I've made the same observation on my socket-A XP motherboards (Asus A7V600-X, Epox EP-8KMM3I) during testing too. It is not a program bug but the issue of whether the motherboard supports the mobile CPUs (Mobile Athlon 4, XP-M, mobile Duron, Geode NX etc.) The desktop socket-A motherboards during that era were not designed to support mobile CPUs, their CPU VRMs couldn't be lowered to the Vcore needed by the mobile CPU, so they are stuck at the minimum Vcore that the motherboard could support. Adding to this complication is that the VID coding of the socket-A mobile CPU is different from that of the desktop CPU (fab51 website has very detailed info on this issue). Only some motherboards have the proper hardware for mobile CPUs support; for those that didn't, the CPU could request the desired Vcore via the VID pins but the motherboard just couldn't do it.

One thing that is curious though is you mentioned the Vcore could be lowered after using setmul. I'm puzzled and will take a look again.

In case of most VIA desktop chipsets enabling mobile Athlon support is possible by toggling some bits in PCI address space of the chipset.
Some are documented (including KT400 that is very similar to KM400 but without integrated graphics) :
https://web.archive.org/web/20170822100906/ht … html/Tweaks.htm
I talked about this with Gerwin earlier so he most likely applied some tweaks in SetMul:
Re: SetMul - Multiplier control for VIA C3 / AMD K6 Mobile / Cyrix 5x86

@Falcosoft,

Thanks for the great info! I'll check it out.

kalohimal wrote on 2020-09-09, 03:49:

Yes, I've made the same observation on my socket-A XP motherboards (Asus A7V600-X, Epox EP-8KMM3I) during testing too. It is not a program bug but the issue of whether the motherboard supports the mobile CPUs (Mobile Athlon 4, XP-M, mobile Duron, Geode NX etc.) The desktop socket-A motherboards during that era were not designed to support mobile CPUs, their CPU VRMs couldn't be lowered to the Vcore needed by the mobile CPU, so they are stuck at the minimum Vcore that the motherboard could support. Adding to this complication is that the VID coding of the socket-A mobile CPU is different from that of the desktop CPU (fab51 website has very detailed info on this issue). Only some motherboards have the proper hardware for mobile CPUs support; for those that didn't, the CPU could request the desired Vcore via the VID pins but the motherboard just couldn't do it.

One thing that is curious though is you mentioned the Vcore could be lowered after using setmul. I'm puzzled and will take a look again.

Yes, i already knew that ;p

"Cool'n Quiet", or "PowerNow", chipset registers are available from Via KT133A (second revision, not all KT133A) and newer VIA chipsets, but only enabled by default on KT266 or newer, because switching multiplier on the fly in KT133A was highly unstable, i did some bios modifications for my KT133A boards to support PowerNow, and i think that was the reason they did not came with the registers enabled by default hehe.

Then, there are the inconsistencies on how motherboards recognize mobile CPUs, The Asus i mentioned boots the processor at 100x5 at 1.6v (instead of 100x14 at 1,45). It simply does not have the CPU identification properly set in bios for this mobile CPUs, but anyway Cool'n Quiet registers are enabled and allows multiplier and voltage changing on the fly by software (Chipset register 55 if i remember right, at least in KT133A).

Some desktop boards do not set the multiplier and voltage right for mobile CPUs, some it is just the voltaje, only very few do it 100% right, it is a matter of the bios, but all are able to supply a voltage of 1.45 or less as there are desktop Athlons with that low voltage. but anyway thanks to tools like Setmul and your amazing CpuSpd this can be solved on mobile CPUs without booting to Windows to use other tools, or needing a motherboard with Bios or jumpers overclocking capabilities.

Now the behavior of CpuSpd in this case:

Boot the computer
Run: "cpuspd f"
cpuspd says the fid/vid is: 0D0B (5x and 1,65v in this case. The hex values might be wrong because i am writing from the top of my head, but they were something alike)
Run: "cpuspd f1610" (in order to get 14X multiplier and 1,45v)
cpuspd answers the fid/vid has been correctly set at 160B (only the multiplier side changed, not the vid)
It does not matter how many times i run the same command, vid never changes.

Then i run: "setmul 10" (for example, any other multiplier would do)
Multiplier gets changed to 10x
then i run: "cpuspd f1610"
cpuspd answers that the fid/vid has been changed to 1610

Profit.

So there is definitely some register somewhere that Setmul is enabling but CpuSpd assumes as enabled. I hope this helps to make this app better.

I also would like to suggest that the help text should be updated, i spent some time before realizing the parameter C1D or C1E could be used to manipulate level 1 cache independantly, thanks to the forum. The C1X paramater does not even appear in the help text. and i think there are others.

@Falcosoft

Do you know what registers are these referring to? I assume they are pci config registers since they are related to the chipsets, but which device is it? Is it the host bridge config space?

I am testing using a KM400 board (which is KT400 with video), and dumped the config space of the host bridge:

Bit 2 of register D5 of the host bridge is already set (0x1E), but I'm still unable to change the VID. FID could be changed freely though.

It is really a challenge to find the datasheets for these chipsets. I could only find 2, the KT133 and AMD761. In these datasheets, the info doesn't match.

Fot KT133, register D5 of the host bridge is defined as "reserved", and no further info is available. For AMD761, register 44 is "BIU control" (whatever that is), and bit 0 is defined as read-only.

I have found another issue, a minor one.

I am playing with an AMD Geode NX1500 (6.8.1) in a HP T5720 Thin Client (Sis 741 Chipset) and the CPU allowed multipliers are incorrectly identified in CPUSPD.

It says allowed multipliers are "Min: 4.0, Max: 4.0", when it should say "Min: 3.0, Max: 24.0"

It is only a cosmetic bug, this CPU is locked at 7.5X max, and i can change it freely between 3x and 7.5x using CpuSpd without issue, only the reporting message is incorrect.

Also i would like to make a feature request; Showing the actual CPU frequency when changing multiplier. When playing with various CPUs on various systems, it is hard to remember how many MHz are which multiplier, and i have to use other tools to check what i am doing after every change.

Cheers

And... i found another one;

Mainboard: VIA EPIA 5000AG
CPU: VIA EDEN (6.9.8 Nehemiah) 133x4=533 Mhz

CpuSpd reports the multiplier can be changed to 3.5 but it cannot be, and when it tries the CPU freezes. The minimum multiplier for this CPU seems to be 4.0 as reported by Setmul.

Can cpuspd also support the old Dixon/Mendocino Celerons for throttling?
I am trying to slow down my 300MHz IBM Thinkpad 240 but using cpuspd t 2 will not seem to do anything - cpuspd a will simply report throttling at 8/8 (no impact to TSC).

amazing tool. i want to report it works flawlessly on my FIC AD11 (AMD 761 northbridge, VIA 686B southbridge) running an Athlon XP 2000+ and a GeForce Ti4200.

thanks to this app, i can play Resident Evil 1 on this machine. normally, the game runs just a bit too fast, the cutscenes desync, and the game eventually freezes. the game runs at a perfect speed with a throttle setting of 2/16. great work!

Can this program work on a Windows 3.1 DOS session windows? As in it works as a TSR and it automatically turns off the CPU internal cache when in DOS session? Did you also tested this on Windows 3.1? I'm surprised no one made any videos of this .

oh no! 😳

system:
Duron 1300 (DHD1300AMT1B)
Soyo SY-K7VTA-B (VIA KT133/686B)
512MB RAM
Voodoo4
Win98 SE in DOS mode

edit: segmentation fault happens with v2.0 also, but v1.5 works!

I have tested all versions of this utility on my Mobile Pentium 4 2.3 GHz (SL789) and it says that multiplier control is not supported. According to the specifications:
https://ark.intel.com/content/www/us/en/ark/p … 00-mhz-fsb.html

SpeedStep is supported for this CPU, but it still doesn't work. Is it the same with this utility for all Northwood mobile CPUs?
Another reason for this could be that my board BCM BC845DL doesn't recognize this CPU. I was hoping that I will be able to set multiplier manually because the CPU defaults to its base 16x multiplier.

EDIT:
It seems that for this Mobile P4 the only way is to use compatible board which supports SpeedStep on a HW level:
Re: P4 multiplier
And it's unlikely there's such board for desktop computers.

Sadly CpuSpd didn't help me with Pentium 3 installed into Toshiba 2805 laptop. I was trying to slower CPU for Daggerfall, but even according to provided table I don't have much options with this tool.

Problem was somewhat solved via Toshiba power app in Windows. I slowed CPU from 900mh to 450 and that was sufficient for Daggerfall. Wonder if CpuSpd could learn same trick. As i understand Toshiba alters CPU clock modulation.

Took a better look, multiplier stays the same in windows, always 9х, but the bus speed is changing. It can be 100, ~75, ~50, ~25.

Development and support had stopped for this project, and the source codes are now released to public domain. Please see 1st post.

Hello Vogons!

First of all, apologies for resurrecting this thread, but I think this is the best place to share some experiences that may help someone.

I'm building a (few) retro system(s) for my personal enjoyment. In this case, this is an AMD K6-III+ based one targeted for early Windows 9x and DOS games. I've been testing different slow down tools to be able to play some DOS titles. The one I like the most is cpuspd as it can do a lot of things in a single command execution line.

So, what's going on... Well, here goes in short.
The issue: With cpuspd I can change the multiplier setting, disable/enable cache and K6 prefetch, on the fly without rebooting. However, it didn't allow me to throttle the CPU when EMM386.EXE is loaded (in EMS or XMS configuration).

The solution: Make sure EMM386.EXE does not use the high memory area between F400-F7FF. Which is easy enough to exclude by just adding X=F400-F7FF in the EMM386.EXE config.sys line, i.e., DEVICE=C:\WINDOWS\EMM386.EXE RAM HIGHSCAN X=F400-F7FF

Perhaps you are more curious now, or you are just bored and wanted to continue reading...
This is my system:
Soyo 5EMA-PRO (VIA VT82C598 APOLLO MVP3 + VT82C686A)
AMD K6-III+ running at 616MHz (112x5.5)
384MB of RAM CL2
Voodoo 3 3000 AGP
LG IDE DVD
2x Patriot P210 128GB SSD with Startech SATA to IDE adapters
D-LINK DFE-538TX 10/100 mbps (RTL8139)
Sound Blaster AWE64 Gold + MT32-pi

I'm sharing the full specs because like they say "your mileage may vary".
As mentioned above, everything in cpuspd worked perfectly fine, with the exception of throttling the CPU.
What I observed is that I could actually throttle the CPU (cpuspd t<number>) when I booted using only conventional memory. Also, it worked perfectly fine when QEMM 8/9 was in place, so what was causing all the trouble had to be something related to the high memory area.

In the cpuspd documentation (readme.txt), there is an eye-opening statement that made perfect sense in this scenario:
"CPU throttling - this function is available to all systems that support ACPI. [...] Please also note that some programs will over write the ACPI data that the BIOS deposited in high memory".

Using umbchk and umascan I compared all configurations: QEMM, EMM386 extended/expanded, conventional memory only... Until, I was able to identify the area of high memory that EMM386 was overwriting that was preventing cpuspd throttling mechanism from working.
In your case that specific memory area maybe a different one. I have plenty of RAM (conventional, higher...) so losing a few KB of high memory is not a concern at all and I prefer to use a single command that can take care of everything.

I understand no one is probably maintaining or doing any extra developing on this useful tool anymore 🙁 In any case, it's worth to bring up that another DOS tool called "throttle" (it's also mentioned in the cpuspd's readme) works fine in whatever memory configuration you boot your system on.
Hence, I believe this ACPI detection can be done (improved) in cpuspd in a similar fashion, so there is no need to exclude any portion of the upper RAM specifically.

Hope it helps!