konc wrote on 2022-12-06, 09:38:
Chkcpu wrote on 2022-12-05, 22:00:Thanks PC@LIVE, yes any CHKCPU report is welcome. :) […]
Show full quote
Thanks PC@LIVE, yes any CHKCPU report is welcome. 😀
About the really Vintage PCs, does any of you have a 8086/8088 system available to test CHKCPU on?
With the unusual high speed reading on konc's V20 CPU, I'm curios what the original 8086/8088 would show. 😉
Thanks, Jan
If none has one handy I'll put back the original 8088 that got replaced by the V20 and give it a run
@konc, That would be great, thanks!
To explain why I ask y’all for these testruns, here is my story on measuring the CPU speed.
I developed CHKCPU as a small and handy tool to display specific data from the CPU in a PC. Often the two most interesting items are the CPU model and the CPU speed.
Apart from detecting the correct CPU model, I always tried to get the speed reading as accurately as possible when adding support for new CPUs to the program.
Nowadays, on Pentium and later, we have an internal Time Stamp Counter (TSC) that runs at the CPU clockspeed. You only have to setup a reliable timebase and read the TSC at the beginning and end of that time interval to get an accurate value of the CPU speed.
But the 486 and earlier don’t have a TSC and have to rely on instruction timing to measure the speed. Because of microcode differences, instruction timing differs between CPU vendors but also between parts of the same vendor. This makes CPU speed measurement via instruction timing quite unreliable.
Usually a lot of slow divide instructions in a loop are used and the program times the duration with the motherboard general purpose timer 2. Like timer 0 and timer 1, these interval timers are always clocked at a fixed 1.1932MHz rate.
The amount of time a divide instruction takes is not only dependent on the internal CPU speed, but also on the CPU family, make, and model. A divide on a 8088 takes about 150 CPU clock cycles, while a Pentium only need 25 clocks. So the software has to know all these details per CPU model, to make a correct speed determination in each case.
When starting work on CHKCPU back in 1996/1997 I found a solution in code samples from the book “The Undocumented PC” by Frank van Gilluwe, where correction tables for each CPU vendor and each CPU type per vendor are used to correct the instruction timing. This code also increases the number of timing loops for faster CPU models, to keep the measurement accurate.
I have since expanded these tables with new CPU types and vendors, and added code to use the TSC instead of instruction timing when possible.
Because modern CPUs all have a TSC, I did not expand the instruction timing tables beyond the Intel Nehalem/AMD Phenom.
This solution works quite well under DOS and Win9x. From Win NT4 onwards, a lot of direct hardware access is virtualized and the speed measurement is often too low and sometimes completely off, even when using the TSC.
This stimulated me to start writing a Win32 console mode version Chkcpu32 v2.xx back in 2004. And of course, the Cpuspeed routine for that had to be rewritten from scratch!
But this is a subject for another topic. 😉
Jan.
