With Jazefox's help in testing the program on his VIA Esther, a few bugs were fixed and several new features are discovered and added, and the changes are updated in CPUSPD version 2.0a service release.

Esther now has these additional features:

• branch prediction on/off
• i-cache on/off
• d-cache on/off

I couldn't get the Tcore reporting to work on Esther (sorry), so it is removed until further notice.

Many thanks for the significant new update, and elimination of the double fault errors on core i systems. Your program keeps getting better and better. This is fabulous indeed, I'll say the best utility of the year 2020 for DOS *by far*!

I have a 5th Gen core i5 , the 5200 and I can now report that the -t and -o options work, with 16 degrees of granularity. However, please note that the -o and the -t settings seem to be identical for me, ie, -t1 and -o1 throttle the system down exactly the same amount. One seems to not affect the other. In other words, instead of 256 degrees of granularity, there are only 16 degrees, -o1 and -t1 seem to do exactly the same thing. Is this the expected behavior?

Also, do I understand you correctly that you have implemented MUL modification on all core i up to 4th generation, but not beyond 4th Gen? I can't adjust multiplier on my i5200. Still the same strange business where I can adjust fidvid from 1500 to 1900 only (system speed increases from 2.1 Ghz to 2.5 Ghz), but all other fidvid values either freeze or do nothing. Is this some weird motherboard and / or BIOS limitation, or is it perhaps CPU specific?

I can adjust multiplier and voltage on all my Core2Duo systems. and the granularity is just spectacular!

I also have an i7 2600k desktop and an i5 8230 laptop. I shall test these CPUs more thoroughly soon, but I also note that on simple testing on the i5 8230, no fidvid settings have *any* effect, unlike on my (lucky?) i5 5200 where I could increase cpu ~15% beyond nominal from 2.1 Ghz to 2.5 Ghz, yet not decrease the multiplier. Further, the 8th Gen i5 does not produce any double fault crashes either.

Hi zyzzle,

Thanks for the kind words, really appreciate it.

The -o and -t controls different things, the first controls the ODCM (on demand clock modulation) built into the CPU, while the second controls the ACPI throttling function in the south bridge. The net effect should be cumulative, you should get 16x16 granularity. Intel documents, however, mentioned that ODCM is for the "P6" CPUs, which in strict sense doesn't include the core ix, but the docs also said that the ODCM control register is an architectural MSR (meaning it is available for all newer CPUs), so there is a bit of conflicting info here. I've never tested it on an core ix gen5, so I'm not sure if Intel changed something there or had removed it. I could however do some test on core ix gen4 (I don't have anything newer than that) and see how it behaves.

Multiplier control is not yet implemented for all core ix. Intel changed the hardware starting from core ix gen 1 and deprecated the old Speedstep MSRs (AMD did the same on their K10). But for core ix gen 1 &2, writing to the old Speedstep MSRs still seem to work on the FID portion, and that's probably the reason why you can still control the multiplier. VID is gone and writing to it doesn't do anything. The old FIDVID thing is replaced by a new mechanism calls "PStates" (performance states), same for both Intel & AMD. I'm currently in the process of writing the code for this (AMD portion is completed, Intel portion still to work on, and meanwhile I'm distracted by the Transmeta CPU which is in the newly bought HP T5710 thin client 😉). For core ix, I think I'll only support up to gen 4 max for 2 main reasons, one is already mentioned as I do not have any CPU newer than gen 4. Second reason is PCI slots are fast disappearing from newer generation of motherboards, and without them there won't be any sound for DOS games, so supporting them is like kinda pointless.

At the moemnt, AMD K10 and Intel Core ix multiplier and fidvid support (via Psates) will most probably be available in the next release, so please do look out for it. Cheers.

I used this program on a I815 chipset laptop with a mobile PIII 850. Was able to throttle to 1x and disable L2, thats about as much as I can do with it. which got me to about a P133mhz in speed sys. Id like to be able to go slower without disabling the l1 becasue then the cpu is too slow. Any advice or other programs I can run with this?

Hi, can I confirm with you the cpuid of your CPU is (6,8,A) please? Please run "CPUSPD d i" and post the result here, as according to the datasheet the mobile PIII should have Speedstep, so you should have mul/fidvid control too. Also, if you disable the cache system (cd) and leave throttle (t) alone, what speed would you get?

will check says fid/vid control is not supported. Also it says Multiplier control is not supported. . As its a Pentium III

Ok. According to Cpuworld and also Intel product specification it should have Speedstep, but the CPU reported otherwise. Bit 7 of ecx should be set if Speedstep is indeed available, but your output shows that ecx is 0. Strange indeed. Perhaps your CPU is an early version which does not have Speedstep implemented? In this case you only have cache system and south bridge throttle to play with unfortunately.

It has speedstep application in windows, that works. I do not know if it is throttling the CPU or changing the the multipliers, not sure how I can tell the difference.

SpeedStep on PIII I guess just changes the Bus Speed.

Perhaps you could try to achieve the speed you wanted by playing with the cache system and throttle. Attached here are the results I obtained long time ago while experimenting, developing and testing the program. Please ignore the "L1" entry, as it is not possible to control L1 alone on the PIII (result is the same as turning the entire cache system off). Also, "throttle 7" here means "t1", "throttle 6" means "t2" etc, it was old terminology I used following the old Throttle.exe, before I changed it to the current one (as I think using a fraction like 1/8 to represent slower speed makes more sense).

Warlord wrote on 2020-08-14, 09:35:

It has speedstep application in windows, that works. I do not know if it is throttling the CPU or changing the the multipliers, not sure how I can tell the difference.

SpeedStep on PIII I guess just changes the Bus Speed.

From the attached picture, it can be seen that the multiplier is still at 8.5x, but the bus frequency has dropped to 26MHz. It certainly looks like some kind of throttling, or changing the clock speed via the external clock generator. If it is done via Speedstep, then the multiplier should change instead of the bus frequency.

I guess this is speed step version 1. Thanks for advice. I'll try some things.

This is the laptop.
https://support.dynabook.com/support/staticCo … omTOCLink=false

zyzzle wrote on 2020-08-14, 06:09:

I have a 5th Gen core i5 , the 5200 and I can now report that the -t and -o options work, with 16 degrees of granularity. However, please note that the -o and the -t settings seem to be identical for me, ie, -t1 and -o1 throttle the system down exactly the same amount. One seems to not affect the other. In other words, instead of 256 degrees of granularity, there are only 16 degrees, -o1 and -t1 seem to do exactly the same thing. Is this the expected behavior?

Hi zyzzle,

I've tested the program on my 1150 system (with G3260 cpu) and had confirmed your observation. Using the -t1, -o1, and -t1 o1 commands all yielded the same results, giving doom real ticks of ~4240. I'm not sure what is causing this, it looks really weird to me, as the -t command programs the south bridge and the -o command programs the cpu. Perhaps Intel had changed something that I'm not aware of. As of now, I'm completely puzzled and have no fix nor answer to this problem...

Some preliminary test results of Transmeta TM5x00 & AMD K10:

Transmeta TM5x00 (tested on the HP T5710 thin client) Doom realticks, using P-state and throttle control:
Max speed: 926, equivalent P166 mmx
S4 (300MHz): 1254, equivalent P100
S4 + T8: 2374, equivalent Cx486DX4-100
S4 + T4: 4730, equivalent i486DX-33
S4 + T1: 20437, equivalent Am386SX-33
Unfortunately the CPU does not support cache control. It has the CR0 register, and allows r/w to CR0.CD (cache disable bit), but does nothing.
The south bridge is VT8231 and has 16 steps resolution.

AMD K10 Doom realticks, using P-state and throttle control:
In addition to FID (multiplier) and VID (voltage) control, it now has an additional DID (frequency divider). The frequency divider is represented by 2^DID, and valid DID is 0 to 4, giving max divider of 2^4 = 16.

Test platform: Gigabyte GA-770T-D3L (AM3) + Athlon x2 250.
FID0 + DID3: 1472, equivalent P90
FID0 + DID4: 2780, equivalent i486DX2-66
CD + FID6 + DID1: 4701 , equivalent i486DX-33
CD + FID0 + DID2: 9623, equivalent i486SX-16
CD + FID4 + DID3: 13949, equivalent i386DX-33
CD + FID0 + DID4: 31964, equivalent Am486SX-25
CD + FID0 + DID4 + T8: 71677, equivalent 80286-8

As you can see, with the addition of DID, it is now extremely flexible with great granularity, and can be fine tuned to many old generation CPUs. With the AMD770 chipset + SB710 south bridge which offer 16 steps throttle, it's granularity is now = 2 (cache) x 15 (multiplier) x 5 (DID) x 16 (throttle) = 2400 steps. Unfortunately, for VID control AMD has followed Intel footstep, in that all cores must be programmed to the lower VID before the VID change will take effect. This again will require multi-core programming in DOS, and I'll need more time to make it happen (or perhaps I should just leave VID out since it seems not many people bother about it anyway?).

For Intel Core ix, per Intel's documents, Intel had implemented "hardware p-state" where the CPU will automatically switch p-states as it deems fit. The OS can "hint" the CPU to go to a particular p-state, but whether the CPU will do it is not guaranteed. I've yet to test it out but now it doesn't look too promising.

kalohimal wrote on 2020-08-16, 14:53:

I've tested the program on my 1150 system (with G3260 cpu) and had confirmed your observation. Using the -t1, -o1, and -t1 o1 commands all yielded the same results, giving doom real ticks of ~4240. I'm not sure what is causing this, it looks really weird to me, as the -t command programs the south bridge and the -o command programs the cpu. Perhaps Intel had changed something that I'm not aware of. As of now, I'm completely puzzled and have no fix nor answer to this problem...

Further testing on my 8th gen core i (i5 8250) reveals the the -o setting works, with 16 degrees of granularity), but the -t setting doesn't work at all. For example with option-t1 the program says "Throtle set to 8/8 (maximum), and also the same for -t2 ... -t8. All the same message. With -o1 it works at 1/16, and prints the proper message, as intended.

On my core i5 5200, the -t setting *appears* to work, but doesn't (CpuSpd says "Throttle set to 1/16", but in practice it does nothing. Strange that it would print different messages compared to my core i5 8250, appear to "take" but do nothing. As to the mystery, it is very very strange, and I understand how puzzled you are!

As to VID support, I would use it often to save power (lower VID) if that feature were available on CpuSpd (for core i systems). Probably would be lots of work to you to figure it out -- as in learning how to reduce VID on all cores to same VID in DOS , but the feature would be used and appreciated!

Core ix gen 4 and beyond use UEFI bios as compare to conventional bios, and changed from conventional port i/o to mmio for pcie. I don't expect the program to work under UEFI bios for throttling, as it searches the bios for ACPI info, which the format is completely changed in UEFI. It also needs port i/o and won't work with mmio. As the objective of the program is for supporting DOS retro gaming, and with new generation CPUs like Core ix there is no more support for PCI sound card and Windows 98, it doesn't make sense to have the program incorporate features that is not practical. In fact I'm now contemplating of supporting Core ix up to gen 2 only, or perhaps none at all, since these modern CPUs have moved on to newer hardware features and lacked the necessary hardware for the program to work.

Btw just an update on the AMD K10. I've completed coding for the multi-core setting of VID yesterday. Initial test is quite impressive: the K10 CPU I used for testing is the AthlonII x2 250, and its nominal Vcore is 1.25V. The spec is 0.85V - 1.425V, but my jaws dropped when I experimented with its Vcore and was able to set it to 0.4375V! (with FID=0 and DID=4, yielding 100MHz which is the slowest frequency possible.) Temperature drop was about 10 deg C and the heat sink was cool to the touch. And yes the system is still stable enough to play DOOM. 😊

kalohimal wrote on 2020-08-20, 03:44:

Core ix gen 4 and beyond use UEFI bios as compare to conventional bios, and changed from conventional port i/o to mmio for pcie. I don't expect the program to work under UEFI bios for throttling, as it searches the bios for ACPI info, which the format is completely changed in UEFI.

Hi,
If a board is UEFI only then you cannot run any kind of DOS on it anyway. Currently even the newest FreeDOS version cannot boot in native UEFI mode. Classic MS-DOS and other legacy DOS versions are of course also out of question. So if a board is UEFI only then the problem is not that your program 'does not work', but even cannot run since the required OS (DOS) cannot be installed on it.
http://wiki.freedos.org/wiki/index.php/UEFI
But if a board supports CSM (Compatibility Support Module) then it should provide legacy BIOS mode with BIOS compatible ACPI tables etc.
Without this you could not even install 32-bit Windows with CSM enabled on these boards since even 32-bit Windows 10 working in BIOS/Legacy mode expects proper BIOS/ACPI tables. So even if a board is an UEFI one if it supports CSM (most desktop ones do) then it should support all the BIOS features your program requires.

BTW I can not wait to test your new version with the AMD K10 enhancements. It sounds promising!

Yeah that make sense, since DOS is largely based on BIOS interrupt services. For version 2.1 I think still need quite a lot of work, Transmeta & K10 support is more or less completed, but I have yet started on the Core ix. And thank you very much for your help in providing info on the K10.

@zyzzle

Found this while reading through Intel's documents today. Perhaps this register explains why some of the Core ix systems wouldn't work with f & m command anymore. Once this bit is enabled, there is no way to turn it off, short of resetting the system. So if the BIOS sets it when booting up, then we're out of luck. The "legacy performance control" (speedstep) is turned off, hardware performance control (HWP) kicks in, and it can never be disabled.

Excerpt from "IA-32 Intel® Architecture Software Developer's Manual, Volume 3, System Programming", page 3B 14-7.

That explains the strange behavior. I suspected it was a BIOS problem. So, without disassembling the BIOS (both of my core i systems obviously have the CSM, so I can thankfully boot DOS natively), and manually setting the MBR for the HWP_ENABLE bit to 0, we're out of luck. Thanks for the information. I'll check my BIOSes thoroughly. Perhaps the is a setting to manually enable and disable "processor p states", but I doubt it. As to disassembling the CSM code of the BIOS, I'm sure that's encrypted and impossible to reverse engineer anyway. Although some great BIOS hackers have done some amazing things over the years!