kalohimal wrote on 2020-06-11, 00:53:

SuperSirLink wrote on 2020-06-10, 21:11:

Setmul does seem to change my CPU multi, and running your program with the a switch reports the same...

Hi SuperSirLink,

Does that mean CPUSPD couldn't change the multiplier but Setmul can? Or do you mean it works the same as Setmul? Hope it's not another bug...

Sorry, I meant that neither is able to set the multiplier...

SuperSirLink wrote on 2020-06-11, 02:42:

Sorry, I meant that neither is able to set the multiplier...

Is your PII-400 an engineering sample? Because as far as i can remember, Intel started locking their CPUs from PII Deschutes onwards, and max frequency of Klamath is 300MHz, so your 400MHz CPU should be Deschutes or later which is supposed to be locked?

Edit: Ok nvm, now I recalled some PII Deschutes were unlocked too. Intel started locking them from week 21 1998, and your unlocked PII-400 is a rare breed, they were introduced in April 98 and in May 98 Intel started locking them...

I do not have any multiplier unlocked Deschutes, but I think I have a Klamath 233 & a 440BX board lying around somewhere. Let me dig it out and take a look.

kalohimal wrote on 2020-06-11, 03:02:

Is your PII-400 an engineering sample? Because as far as i can remember, Intel started locking their CPUs from PII Deschutes onw […]
Show full quote

SuperSirLink wrote on 2020-06-11, 02:42:

Sorry, I meant that neither is able to set the multiplier...

Is your PII-400 an engineering sample? Because as far as i can remember, Intel started locking their CPUs from PII Deschutes onwards, and max frequency of Klamath is 300MHz, so your 400MHz CPU should be Deschutes or later which is supposed to be locked?

Edit: Ok nvm, now I recalled some PII Deschutes were unlocked too. Intel started locking them from week 21 1998, and your unlocked PII-400 is a rare breed, they were introduced in April 98 and in May 98 Intel started locking them...

I do not have any multiplier unlocked Deschutes, but I think I have a Klamath 233 & a 440BX board lying around somewhere. Let me dig it out and take a look.

Yeah, that’s correct though I heard it was week 38 of 1998. I have a 333, 350, and a 400 that is unlocked. I can set the multiplier in the BIOS.

Ok I managed to find the PII Developer's Manual. On page 5-8 it was mentioned this is set using the "Power-On Configuration Register". This is a scheme entirely different from SpeedStep, and that's the reason why CPUSPD/Setmul can't change it. Let me take a look, might include it in the next revision if I can get it working.

- David W.

After some careful reading of this document, it seems that the multiplier bits in "Power-On Configuration Register" (bits 22-25) are read only. They are set according to the CPU pins during power up. This implies that they are set by the motherboard upon booting, perhaps using some external circuitry to provide the bit pattern to the pins, and hence cannot be changed within the CPU. Sorry...

kalohimal wrote on 2020-06-11, 04:22:

After some careful reading of this document, it seems that the multiplier bits in "Power-On Configuration Register" (bits 22-25) are read only. They are set according to the CPU pins during power up. This implies that they are set by the motherboard upon booting, perhaps using some external circuitry to provide the bit pattern to the pins, and hence cannot be changed within the CPU. Sorry...

No worries! Thanks for taking the time to look into it!

kalohimal wrote on 2020-06-03, 13:56:

CPUSPD version 1.1 released. Resolve incompatibility issue with Yamaha's DSDMA sound driver. Please download from first post.

Sound card test results:

Please note that we are only testing the proper functioning of the CPUSPD program here. Some sound cards might experience stuttering on certain motherboards, due to poor implementation of the throttling function in the south bridge.

So is the G41 chipset runs DOS with PCI soiudncard?
Are you using freedos ?

SuperSirLink wrote on 2020-06-11, 12:56:

No worries! Thanks for taking the time to look into it!

You're most welcome.

MKT_Gundam wrote on 2020-06-11, 14:32:

So is the G41 chipset runs DOS with PCI soiudncard?
Are you using freedos ?

Yes it can, and I've tested many mobos with G41, but I've not tried FreeDOS. No reason that it won't work though. For the games I tried, mostly are on DOS7 (the one from Win98), sometimes DOS6.22.

kalohimal wrote on 2020-06-11, 14:37:

MKT_Gundam wrote on 2020-06-11, 14:32:

So is the G41 chipset runs DOS with PCI soiudncard?
Are you using freedos ?

Yes it can, and I've tested many mobos with G41, but I've not tried FreeDOS. No reason that it won't work though. For the games I tried, mostly are on DOS7 (the one from Win98), sometimes DOS6.22.

The Intel chipsets after 8xx series, break the compatibility of pci soundcards in DOS.

MKT_Gundam wrote on 2020-06-11, 23:04:

The Intel chipsets after 8xx series, break the compatibility of pci soundcards in DOS.

Yes that's right, they no longer support PC/PCI and DDMA. But with Yamaha YMF744 and a set of modded drivers (specifically modded setupds.exe) + Yamaha's dsdma (a small protected mode TSR driver which reroutes the DMA), you can do wonder. 😀

The only problem with chipsets after i845 is that they no longer have Windows 98 drivers. So while they can do DOS and XP just fine, they can't run Win 98 (well they still can with some mobos, but with only generic drivers for hdd controllers etc).

I've great success with using the Yamaha YMF744 on many mobos, with chipsets from Intel, VIA, ALi/ULi, and SiS, by just using the modded driver and TSR mentioned above. The only exception is nForce chipsets, which is incompatible. Please see compatibility sheet from Kamarat, and also ruthan's thread where he successfully used it on X58 + ICH10R board.

Also in this thread, I have show case a socket 939 system (with ULi chipsets) for DOS/98/XP gaming. Cheers.

- David

Dude, this is a win. Thank you for this great alternative! I'll run some thorough tests later this week on the sig PC, since I use Throttle all the freaking time, but right now basic throttling state switching works exactly like it should (i815, pure DOS).

Quick question: is it also possible to implement a SetMul-like Level 2 cache control in subsequent versions?

kalohimal wrote on 2020-06-02, 11:29:

The original Throttle is also a real mode program, so it cannot execute when the PC is in VCPI mode (when EMM386 is running) or protected mode (When Windows 9x is running).

Strange, it does execute and work perfectly fine with or without EMM386 on my config, including Windows 98/ME. What gives?

UPD.: Can confirm CPUSPD also works fine in WinME :)

Revolter wrote on 2020-06-14, 14:01:

Quick question: is it also possible to implement a SetMul-like Level 2 cache control in subsequent versions?

For older CPUs there are registers in the CPU that allow control of the L1 & L2 cache separately. For more modern CPUs Intel & AMD seemed to have removed that, as I could not find them in the technical documents. All thats mentioned is how to enable/disable both together. Anyway I think L2 effectiveness in speed control is rather negligible, so there is really no need to control them separately. CPUSPD does turn on/off both L1 & L2 caches together, and when this happen, all instructions is serialized, meaning branch prediction is turned off as well. With cache, multiplier and throttle, you can already get very fine control over the CPU speed (in fact cache + throttle already give you very good control).

Revolter wrote on 2020-06-14, 14:01:

Strange, it does execute and work perfectly fine with or without EMM386 on my config, including Windows 98/ME. What gives?

Throttling should be ok since it is controlled via I/O port. Cache control is another story, as it needs access to privilege instructions. If I remember correctly, if you run Throttle under protected mode/Win9x and try to enable/disable cache, with debug mode on (-d) it will say: "Unable to enable/disable L1 cache due to CPU in protected mode.". Without -d it will just silently ignore the cache control command. You can also verify this by running throttle with emm386 loaded, then run speedsys to check the cache status (or use SETMUL or CPUSPD to check).

Think I worded it incorrectly, it is not that Throttle cannot execute but rather it can no longer control the cache under protected mode. I've edited the text. 😁

kalohimal wrote on 2020-06-14, 15:09:

If I remember correctly, if you run Throttle under protected mode/Win9x and try to enable/disable cache, with debug mode on (-d) it will say: "Unable to enable/disable L1 cache due to CPU in protected mode."

Oh, I see: you were referring to cache disabling, and I meant the throttle levels. You are right: while in Windows there is no way of disabling either cache using these programs. UPD.: I've just tried disabling the caches in WinME and sure enough it worked with your program.

kalohimal wrote on 2020-06-14, 15:09:

For more modern CPUs Intel & AMD seemed to have removed that

It certainly is possible - such thing already exists in the form of CACHECTL utilily here:

CPU Tuning, Throttling
(It reportedly doesn't work with Pentium 4's, but it does with Core 2 CPUs (albeit requiring EMM386 to be off), and I'm sure PARUS would be happy to provide technical details)

I personally believe that if you could somehow combine the features of these separate utilities into CPUSPD, it would be equivalent of dropping an atom bomb on the community, changing it forever 😀

Revolter wrote on 2020-06-14, 16:28:

It certainly is possible - such thing already exists in the form of CACHECTL utilily here: […]
Show full quote

It certainly is possible - such thing already exists in the form of CACHECTL utilily here:

CPU Tuning, Throttling
(It reportedly doesn't work with Pentium 4's, but it does with Core 2 CPUs (albeit requiring EMM386 to be off), and I'm sure PARUS would be happy to provide technical details)

I personally believe that if you could somehow combine the features of these separate utilities into CPUSPD, it would be equivalent of dropping an atom bomb on the community, changing it forever 😀

Thanks for the pointer to the thread, it is certainly very interesting. The MSR 198 and 199 he is using to control Core 2's multiplier, are the exact ones I'm using too (they are Speedstep MSRs). But I'm curious how he could change multiplier without setting it on ALL cores. For Intel Core 2 Dual/Quad, 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 most interesting though is how he separate L1 & L2 cache. I might need to reread the tech manuals, might have missed it.

I'm also contemplating whether to include Cyrix/VIA C3 CPUs multiplier control. It is not difficult, just need to add codes for CPU detection and then read/write to their multiplier control register. Only thing is it's overlapping with Setmul, and since I do not have any of these CPUs, testing them would be rather difficult. Perhaps will do it if there are enough interests?

kalohimal wrote on 2020-06-14, 16:51:

Revolter wrote on 2020-06-14, 16:28:

It certainly is possible - such thing already exists in the form of CACHECTL utilily here: […]
Show full quote

It certainly is possible - such thing already exists in the form of CACHECTL utilily here:

CPU Tuning, Throttling
(It reportedly doesn't work with Pentium 4's, but it does with Core 2 CPUs (albeit requiring EMM386 to be off), and I'm sure PARUS would be happy to provide technical details)

I personally believe that if you could somehow combine the features of these separate utilities into CPUSPD, it would be equivalent of dropping an atom bomb on the community, changing it forever 😀

Thanks for the pointer to the thread, it is certainly very interesting. The MSR 198 and 199 he is using to control Core 2's multiplier, are the exact ones I'm using too (they are Speedstep MSRs). But I'm curious how he could change multiplier without setting it on ALL cores. For Intel Core 2 Dual/Quad, 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 most interesting though is how he separate L1 & L2 cache. I might need to reread the tech manuals, might have missed it.

Hi,
Congratulations for your achievement! So far your utility is the only one that can modify Core2 Fid/Vid values freely. Neither mine nor CPUMSR can set lower multiplier in case of multi-core Core2 CPUs (I have tested). So your hard work was not for nothing 😀

kalohimal wrote on 2020-06-14, 16:51:

I'm also contemplating whether to include Cyrix/VIA C3 CPUs multiplier control. It is not difficult, just need to add codes for CPU detection and then read/write to their multiplier control register. Only thing is it's overlapping with Setmul, and since I do not have any of these CPUs, testing them would be rather difficult. Perhaps will do it if there are enough interests?

Besides Cyrix/VIA C3 CPUs you should also consider adding K10 (Phenom I/II) support for your utility. It's missing from SetMul but I have written a basic utility for this (source is included):
http://falcosoft.hu/dos_softwares.html#pwr
Compared to K8/Core2 it is very simple to set P-states of K10. You do not have to set exact Fid/Vid values (they are programmed by BIOS) you just have to set the P-state values and only on the Bootstrap processor (P-state 0 is the highest performance state and bigger numbers mean lower performance power saving states.)

kalohimal wrote on 2020-06-14, 17:15:

I'm also contemplating whether to include Cyrix/VIA C3 CPUs multiplier control. It is not difficult, just need to add codes for CPU detection and then read/write to their multiplier control register. Only thing is it's overlapping with Setmul, and since I do not have any of these CPUs, testing them would be rather difficult. Perhaps will do it if there are enough interests?

I have a C3 with a 686B southbridge and I'm willing to help with testing.

This may be a stupid/out-of-bounds question.
I have a 486 ISA slot SBC with a VIA VT82C496G chipset. I believe some newer 486 motherboards and laptops also use this chipset. Hardware speed control on a 486 has been a bit of a holy grail for me, however unreasonable. The chipset datasheet says it's capable of adjusting the CPU clock speed using the same method used by the newer VIA chipsets supported by Throttle. Throttle, of course, doesn't recognize this chipset. As I type this, I realize I should just try it. Here is the question anyway: does your utility rely on a particular BIOS feature that may not be present in these older BIOSes? I see no mention of ACPI in the motherboard or BIOS documentation, but it does refer to APM 1.1. The AWARD v4.51 BIOS only has settings for doze, sleep, suspend, and HDD power down.

Falcosoft wrote on 2020-06-14, 19:29:

Hi, Congratulations for your achievement! So far your utility is the only one that can modify Core2 Fid/Vid values freely. Neith […]
Show full quote

Hi,
Congratulations for your achievement! So far your utility is the only one that can modify Core2 Fid/Vid values freely. Neither mine nor CPUMSR can set lower multiplier in case of multi-core Core2 CPUs (I have tested). So your hard work was not for nothing 😀

Besides Cyrix/VIA C3 CPUs you should also consider adding K10 (Phenom I/II) support for your utility. It's missing from SetMul but I have written a basic utility for this (source is included):
http://falcosoft.hu/dos_softwares.html#pwr
Compared to K8/Core2 it is very simple to set P-states of K10. You do not have to set exact Fid/Vid values (they are programmed by BIOS) you just have to set the P-state values and only on the Bootstrap processor (P-state 0 is the highest performance state and bigger numbers mean lower performance power saving states.)

Thanks and really appreciate the encouragement. When this project first started, the objectives were to target P4 and Core 2 CUPs since these were not covered by Throttle/Setmul. It's because if we could use these machines for retro gaming it would be great, as older hardware are getting more expensive by the day while P4/Core 2 systems are cheap. For K10/Core i, as you mentioned they changed the multiplier controlling scheme starting from these CPUs, and so I let them out. From your code (thanks for you willingness to share your knowledge!) it does look like not hard to do, so perhaps will include it further down the road. So maybe for now, the priority would be: C3, K10/Core i, separate L1 & L2 cache.

johnnycontrario wrote on 2020-06-15, 02:25:

I have a C3 with a 686B southbridge and I'm willing to help with testing.

That will be great! Thank you very much for offering your help, I'll start working on it within these few days, and post the beta program here for testing when it's ready.

johnnycontrario wrote on 2020-06-15, 02:25:

I have a 486 ISA slot SBC with a VIA VT82C496G chipset. I believe some newer 486 motherboards and laptops also use this chipset. Hardware speed control on a 486 has been a bit of a holy grail for me, however unreasonable. The chipset datasheet says it's capable of adjusting the CPU clock speed using the same method used by the newer VIA chipsets supported by Throttle. Throttle, of course, doesn't recognize this chipset. As I type this, I realize I should just try it. Here is the question anyway: does your utility rely on a particular BIOS feature that may not be present in these older BIOSes? I see no mention of ACPI in the motherboard or BIOS documentation, but it does refer to APM 1.1. The AWARD v4.51 BIOS only has settings for doze, sleep, suspend, and HDD power down.

As far as I know APM (released in 1992) is the predecessor of ACPI (Dec 1996), so it's hard to tell. I guess the only way is to try CPUSPD on it. Alternatively, if you like to play a little with it, you can use debug to find out as follow:

C:\DOS\debug
-s f000:0 ffff "RSD PTR"
-s e000:0 ffff "RSD PTR"

Please note the space between RSD and PTR. If ACPI is available, it should give you a hex address, like this:
e.g. E000:9E10
Dump the content of that address using the d command:
-d e000:9e10

If it could find the signature "RSD PTR" then ACPI is present for your system.

From the datasheet it does seem to have frequency throttling and clock control functions (page 19-20), though I'm not sure whether it is compatible with the ACPI scheme. I would be very interested to find out too.