Disruptor wrote on 2022-12-13, 00:40:

No, that's wrong. DOS just initializes its timer by BIOS / RTC. But then its clock is based on the timer interrupts. It is a rel […]
Show full quote

debs3759 wrote on 2022-12-12, 23:57:

Disruptor wrote on 2022-12-12, 23:48:

Jan,
do you check for speed differences between DOS clock and RTC clock (if present)?

I'm pretty sure DOS uses the BIOS / RTC for its time.

No, that's wrong. DOS just initializes its timer by BIOS / RTC. But then its clock is based on the timer interrupts. It is a relict from the past since the first IBM PCs did not habe a RTC at all.
I refer to this topic, where a user got his 25 MHz 386 measured as 8 MHz. The reason was that there was a failure on his mainboard so that the timer ran with a triple harmonic frequency of a about 42 MHz instead of 14,318 MHz. https://www.dosforum.de/viewtopic.php?f=1&t=13687 (in German)
The old diagnostics software CheckIt did compare both clocks.

Hi Disruptor,

No, CHKCPU doesn’t querry DOS or RTC for time information, and therefor doesn’t do a crosscheck with the motherboard timers either. So it assumes these crystal controlled timers are running at the correct 1.1932 MHz frequency.

If the timers would be way off, like the fault shown in the dosforum you linked to, then the reported speed by CHKCPU will be way off as well.
But when the 14.318 MHz crystal clockcircuit is running with such a big deviation, an erroneous speed reading by CHKCPU will be the least of your worries. 😉
Other motherboard functions will be way off too, like the basic system timer interrupt and the DRAM refresh logic. Often the board won’t boot at all with such a fault, and I was amazed that the 386 from the OP in that dosforum topic still ran!

Jan

maxtherabbit wrote on 2022-12-13, 02:46:

So the bugfix you alluded to in the previous post regarding the FPU type has not yet been implemented?

Okay, I have to be more clear about this.

Yes, the bugfix to correct the erroneous 287 detection is implemented in CHKCPU v1.26.19.
So when a 386 is paired with a 287 or 387, this will now be indicated correctly in both cases.

What I meant by the ‘generic’ FPU indication is that when CHKCPU shows a 80287, it can be an Intel 80287, 80287XL, AMD 80C287, Cyrix 82S87, or IIT 2C87.
Likewise, an indicated 387 can be an Intel 80387, 387DX, 387SX, 387SL, IIT 3C87, 3C87SX, 4C87, Cyrix 83D87/387+, 83S87, EMC87, 487S/DLC, ULSI 83C87, 83S87, or C&T 38700DX/SX.
Apart from a few functional differences and, more importantly, performance differences, these FPUs are largely identical in their main function.

The goal of this CHKCPU ‘Retro’ update was to add support for 16-bit CPUs and make the 386/486 CPU detection as detailed as possible. As some 486, and all Pentium and later CPU models, with CPUID support already show if they have an internal FPU or not, I wanted to have an indication if an extra FPU is fitted on older systems as well, and I believe I reached this goal. 😉

Of course, it would be nice to have an indication of the actual make and model of the FPU and this will be on my wish list for a next CHKCPU update.
But after I’ve published this Retro update, I want to finish my M912 Award BIOS project first, and then continue with the DIY BIOS patching story.
This will keep me busy for a while. 😀

Jan

Chkcpu wrote on 2022-12-13, 14:34:

What I meant by the ‘generic’ FPU indication is that when CHKCPU shows a 80287, it can be an Intel 80287, 80287XL, AMD 80C287, Cyrix 82S87, or IIT 2C87.
Likewise, an indicated 387 can be an Intel 80387, 387DX, 387SX, 387SL, IIT 3C87, 3C87SX, 4C87, Cyrix 83D87/387+, 83S87, EMC87, 487S/DLC, ULSI 83C87, 83S87, or C&T 38700DX/SX.

Shouldn't the 287XL be detected as a 387?

maxtherabbit wrote on 2022-12-13, 15:22:

Chkcpu wrote on 2022-12-13, 14:34:

What I meant by the ‘generic’ FPU indication is that when CHKCPU shows a 80287, it can be an Intel 80287, 80287XL, AMD 80C287, Cyrix 82S87, or IIT 2C87.
Likewise, an indicated 387 can be an Intel 80387, 387DX, 387SX, 387SL, IIT 3C87, 3C87SX, 4C87, Cyrix 83D87/387+, 83S87, EMC87, 487S/DLC, ULSI 83C87, 83S87, or C&T 38700DX/SX.

Shouldn't the 287XL be detected as a 387?

No, I prevented that.
Although the 287XL is build on a 387 core with its better performance, it is still a 287 FPU in a 287 socket.
CHKCPU would indeed detect the 287XL as a 387 but because it runs on a 80286 system, I let CHKCPU display it as a 80287.
Displaying a 387 FPU on a 286 system would be confusing. 😉

Jan

Chkcpu wrote on 2022-12-13, 21:27:

No, I prevented that. Although the 287XL is build on a 387 core with its better performance, it is still a 287 FPU in a 287 sock […]
Show full quote

maxtherabbit wrote on 2022-12-13, 15:22:

Chkcpu wrote on 2022-12-13, 14:34:

What I meant by the ‘generic’ FPU indication is that when CHKCPU shows a 80287, it can be an Intel 80287, 80287XL, AMD 80C287, Cyrix 82S87, or IIT 2C87.
Likewise, an indicated 387 can be an Intel 80387, 387DX, 387SX, 387SL, IIT 3C87, 3C87SX, 4C87, Cyrix 83D87/387+, 83S87, EMC87, 487S/DLC, ULSI 83C87, 83S87, or C&T 38700DX/SX.

Shouldn't the 287XL be detected as a 387?

No, I prevented that.
Although the 287XL is build on a 387 core with its better performance, it is still a 287 FPU in a 287 socket.
CHKCPU would indeed detect the 287XL as a 387 but because it runs on a 80286 system, I let CHKCPU display it as a 80287.
Displaying a 387 FPU on a 286 system would be confusing. 😉

Jan

I disagree with that reasoning, it is for all intents and purposes a 387 and should be detected as such. Norton System Information for example shows it as "387"

maxtherabbit wrote on 2022-12-13, 21:37:

Chkcpu wrote on 2022-12-13, 21:27:

No, I prevented that. Although the 287XL is build on a 387 core with its better performance, it is still a 287 FPU in a 287 sock […]
Show full quote

maxtherabbit wrote on 2022-12-13, 15:22:

Shouldn't the 287XL be detected as a 387?

No, I prevented that.
Although the 287XL is build on a 387 core with its better performance, it is still a 287 FPU in a 287 socket.
CHKCPU would indeed detect the 287XL as a 387 but because it runs on a 80286 system, I let CHKCPU display it as a 80287.
Displaying a 387 FPU on a 286 system would be confusing. 😉

Jan

I disagree with that reasoning, it is for all intents and purposes a 387 and should be detected as such. Norton System Information for example shows it as "387"

Right, we will disagree on that, but that’s fine.
Your viewpoint is more in the direction of FPU function and what it can do, while mine is more hardware oriented, preferring to show the exact FPU type by its name as stamped on top.
Both valid viewpoints I believe.
But I have to admit that CHKCPU is presently leaning more to your viewpoint with its generic 387 display, except for the 287XL that is. 😉

Jan

Chkcpu wrote on 2022-12-14, 15:30:

Right, we will disagree on that, but that’s fine. Your viewpoint is more in the direction of FPU function and what it can do, wh […]
Show full quote

maxtherabbit wrote on 2022-12-13, 21:37:

Chkcpu wrote on 2022-12-13, 21:27:

No, I prevented that. Although the 287XL is build on a 387 core with its better performance, it is still a 287 FPU in a 287 sock […]
Show full quote

No, I prevented that.
Although the 287XL is build on a 387 core with its better performance, it is still a 287 FPU in a 287 socket.
CHKCPU would indeed detect the 287XL as a 387 but because it runs on a 80286 system, I let CHKCPU display it as a 80287.
Displaying a 387 FPU on a 286 system would be confusing. 😉

Jan

I disagree with that reasoning, it is for all intents and purposes a 387 and should be detected as such. Norton System Information for example shows it as "387"

Right, we will disagree on that, but that’s fine.
Your viewpoint is more in the direction of FPU function and what it can do, while mine is more hardware oriented, preferring to show the exact FPU type by its name as stamped on top.
Both valid viewpoints I believe.
But I have to admit that CHKCPU is presently leaning more to your viewpoint with its generic 387 display, except for the 287XL that is. 😉

Jan

Consider it from the perspective of the user testing an unknown 286 system for the first time. They know for sure it has a 287 socket, of that there is no doubt. But they won't know whether it is a plain 287 or 287xl without opening the system or using a software tool such as yours.

maxtherabbit wrote on 2022-12-15, 03:05:

Chkcpu wrote on 2022-12-14, 15:30:

Right, we will disagree on that, but that’s fine. Your viewpoint is more in the direction of FPU function and what it can do, wh […]
Show full quote

maxtherabbit wrote on 2022-12-13, 21:37:

I disagree with that reasoning, it is for all intents and purposes a 387 and should be detected as such. Norton System Information for example shows it as "387"

Right, we will disagree on that, but that’s fine.
Your viewpoint is more in the direction of FPU function and what it can do, while mine is more hardware oriented, preferring to show the exact FPU type by its name as stamped on top.
Both valid viewpoints I believe.
But I have to admit that CHKCPU is presently leaning more to your viewpoint with its generic 387 display, except for the 287XL that is. 😉

Jan

Consider it from the perspective of the user testing an unknown 286 system for the first time. They know for sure it has a 287 socket, of that there is no doubt. But they won't know whether it is a plain 287 or 287xl without opening the system or using a software tool such as yours.

This CHKCPU ‘Retro update’ is primarily for this community and other retro computer enthusiasts, so I value all your opinions.

@maxtherabbit, thank you for taking the time to clarify your point.
We may not be disagreeing that much afterall. 😉

I now better understand your view that, with CHKCPU’s present generic FPU display, it’s better to show the detected 387 on a 286 system so that the user knows it’s not running the original slow Intel 80287 or AMD 80C287 FPU, but the faster Intel 80287XL, Cyrix 82C87, or IIT 2C87 instead.

I can go along with that, although I still find it a bit weird to show a 387 on a 286 system. What would you say if I changed the 387 indication to 287XL for 286 systems only, while keeping the 80287 indication for the original 287 FPU?
This would hardly take any extra coding effort, and would be a nice first step to a more detailed FPU detection. 😉

As this CHKCPU retro update would be a nice addition to DOScember 2022, I like to publish it this month, preferably before Christmas. 😀
I’m now working on v1.26.20 beta and I plan this to be the last test version before the v1.27 final release.
I just found a bug in the FPU detection on Cx/TI 486 models that needs fixing and I’m looking at the changes for 387/287XL detection on 286 as well.

I will be back when v1.26.20 beta is ready.
Jan

Chkcpu wrote on 2022-12-15, 18:02:

I can go along with that, although I still find it a bit weird to show a 387 on a 286 system. What would you say if I changed the 387 indication to 287XL for 286 systems only, while keeping the 80287 indication for the original 287 FPU?

That sounds like a good plan. Even better, I think you can distinguish between 287XL and 387 on the 80386 by checking the ET bit in CR0. So in my oppinion the perfect solution would display "287XL" on 286 systems and 386DX systems with ET set to "287-like", and "387" on 386DX systems with ET set to "387-like". On 386SX systems, AFAIK the only option is the 387SX.

You should furthermore be able to distinguish the original 387 and the newer 387DX by benchmarking some instructions, but this is likely way beyond the scope of the christmas update.

At least the 387SX does not know 2 cores like the 387 vs 387DX.

mkarcher wrote on 2022-12-15, 18:58:

Chkcpu wrote on 2022-12-15, 18:02:

I can go along with that, although I still find it a bit weird to show a 387 on a 286 system. What would you say if I changed the 387 indication to 287XL for 286 systems only, while keeping the 80287 indication for the original 287 FPU?

That sounds like a good plan. Even better, I think you can distinguish between 287XL and 387 on the 80386 by checking the ET bit in CR0. So in my oppinion the perfect solution would display "287XL" on 286 systems and 386DX systems with ET set to "287-like", and "387" on 386DX systems with ET set to "387-like". On 386SX systems, AFAIK the only option is the 387SX.

You should furthermore be able to distinguish the original 387 and the newer 387DX by benchmarking some instructions, but this is likely way beyond the scope of the christmas update.

Agree

The CHKCPU v1.26.20 beta is now ready and available for download from the first message of this thread.

I’ve addressed the following 4 issues:
- Adjusted the speed reading on Cyrix design 486 CPUs again. Should be correct now.
- Fixed a bug that prevented display of an FPU on Cx/TI 486SLC/DLC/SXLC/SXL systems.
- Added a 287XL FPU display on 286 systems with a second generation FPU based on the 387 core, like the Intel 80287XL, Cyrix 82S87, and IIT 2C87. First generation 287 FPUs, like the Intel 80287 and AMD 80C287, are still indicated as a plain '80287'.
- When an FPU is paired with the 386SX CPU, it is indicated as 387SX. For all other 386 systems, the FPU is still shown as just ‘387’.

@mkarcher, CHKCPU uses the ET bit of CR0 to detect if a 386 has a 16 or 32-bit data path, so it can differentiate between 386SX/386DX, Cx486SLC/486DLC etc. and I implemented your 386SX -> 387SX idea, but the rest of your ‘perfect solution’ has me puzzled. 😉
Can you explain a bit more? Thanks.

Jan

Chkcpu wrote on 2022-12-16, 21:52:

@mkarcher, CHKCPU uses the ET bit of CR0 to detect if a 386 has a 16 or 32-bit data path, so it can differentiate between 386SX/386DX, Cx486SLC/486DLC etc. and I implemented your 386SX -> 387SX idea, but the rest of your ‘perfect solution’ has me puzzled. 😉
Can you explain a bit more? Thanks.

As I understand it, you don't (typically) pair a 386DX with a 387SX, but either (old way) with a 287 / 287XL or (new way) a 387 / 387DX. If a 386DX is paired with a 287, the ET bit is set for 16-bit data path. If a 386DX is paired with a 3878, the ET bit is set for a 32-bit data path. On the 386DX, this bit is only about the data path between processor and coprocessor, that's why it is called "extension type". If I understand you correctly, you are currently displaying a 386DX + 287 (ET set to 16-bit data path) as 386SX + 387SX. On the 386SX, the ET bit is documented to be fixed at 1. The 386DX datasheet I have at hand describes this bit as "reserved, do not modify". According to Intel the processor should automatically detect at RESET whether a 387 is present (setting ET=0) or not (287 or no coprocessor, setting ET=1) by samping the ERROR# line after reset. IBM did not wire the ERROR# signal from the FPU to the CPU as Intel intended, but (starting at the AT) routed the FPU error through the PIC, so this "auto-detection" is inoperative in PC-like systems, requiring the BIOS to manually set ET in CR0.

mkarcher wrote on 2022-12-17, 08:40:

As I understand it, you don't (typically) pair a 386DX with a 387SX, but either (old way) with a 287 / 287XL or (new way) a 387 / 387DX. If a 386DX is paired with a 287, the ET bit is set for 16-bit data path. If a 386DX is paired with a 3878, the ET bit is set for a 32-bit data path. On the 386DX, this bit is only about the data path between processor and coprocessor, that's why it is called "extension type". If I understand you correctly, you are currently displaying a 386DX + 287 (ET set to 16-bit data path) as 386SX + 387SX. On the 386SX, the ET bit is documented to be fixed at 1. The 386DX datasheet I have at hand describes this bit as "reserved, do not modify". According to Intel the processor should automatically detect at RESET whether a 387 is present (setting ET=0) or not (287 or no coprocessor, setting ET=1) by samping the ERROR# line after reset. IBM did not wire the ERROR# signal from the FPU to the CPU as Intel intended, but (starting at the AT) routed the FPU error through the PIC, so this "auto-detection" is inoperative in PC-like systems, requiring the BIOS to manually set ET in CR0.

@mkarcher, thanks for providing another piece of the puzzle about this ET bit in CR0.
I have information from various sources that the ET bit can be used for detecting if a 386 CPU is a 386SX or 386DX, and I understand now better why.

So, on the 386SX the ET bit is fixed because this CPU has a fixed 16-bit data path and can only be paired with an FPU that uses the same databus width (387SX). The nice thing is that the 386SX’s ET bit remains fixed, even if an FPU is not installed.
The 386DX on the other hand needs the ET bit to be changeable to indicate if an FPU with 16-bit or 32-bit data path is connected. I was missing that insight, thank you.
One internet source remarked that later 386DX models couldn’t cooperate with 16-bit FPUs (287) anymore, but that for compatibility reasons the ET bit can be set on any 386-like CPU with a 32-bit bus, but not on those with a 16-bit bus.

Various code samples I’ve seen just try if the ET bit can be toggled, instead of reading its ‘1’ or ‘0’ state. And this is what CHKCPU does as well on 386 systems, to see if it is dealing with a 386SX or 386DX CPU.
So when I spoke about using the ET bit for 386SX/DX detection, I meant “trying if this bit can be changed”.

CuPid (author of CPU-Z) told me a while back that this 16/32-bit buswidth detection works on both Intel and AMD 386s, as well as the 386 upgrade CPUs Cx/TI486SLC/DLC, IBM 486SLC/SLC2 (not tested yet on an IBM 486DLC2/BL2/BL3), and supposedly on Ti486SXLC/SXL (confirmed now, tested by feipoa).
I’m confident it works on the IBM Blue Lightning as well and CHKCPU is using this ET bit toggle logic on all these 386 (upgrade) CPUs to be more accurate in its CPU type display.

Now, for detecting a 287 or 387 FPU, I use the +infinity/-infinity test. On the first-generation 80287 these values were the same, but on 287XL/387 and comparable FPUs, sporting full IEEE 754 compatibility, +infinity is not same as -infinity.
This test makes CHKCPUs FPU indication independed from the 16-bit/32-bit buswidth detection.
Note that I only perform the infinity test when a 80286 or later CPU is detected, because I don’t know how an 8087 or 80187 would react on this test.

To finally answer your question, when an original 80386 or 386DX is paired with a first-generation 287, CHKCPU displays “386DX with 287 FPU”. But when a 287XL or 387 is fitted, CHKCPU displays “386DX with 387 FPU”, while on a 386SX with FPU you will see “386SX with 387SX FPU”.

Jan

Chkcpu wrote on 2022-12-17, 20:59:

The 386DX on the other hand needs the ET bit to be changeable to indicate if an FPU with 16-bit or 32-bit data path is connected. I was missing that insight, thank you.
One internet source remarked that later 386DX models couldn’t cooperate with 16-bit FPUs (287) anymore, but that for compatibility reasons the ET bit can be set on any 386-like CPU with a 32-bit bus, but not on those with a 16-bit bus.

I didn't expect the Intel/AMD 386DX to ever lose this capability, but of course other CPUs made for the 386DX socket (like the 486DLC family of chips) likely never implemented the 16-bit data path required for 287 interoperability. Nevertheless, the claim about late 386DX processors not being able to interface with a 287 might be true, too.

Chkcpu wrote on 2022-12-17, 20:59:

Various code samples I’ve seen just try if the ET bit can be toggled, instead of reading its ‘1’ or ‘0’ state. And this is what CHKCPU does as well on 386 systems, to see if it is dealing with a 386SX or 386DX CPU.
So when I spoke about using the ET bit for 386SX/DX detection, I meant “trying if this bit can be changed”.

That sounds fine. As long as you return ET to the original state, because otherwise you would mess up the coprocessor communication.

Chkcpu wrote on 2022-12-17, 20:59:

Now, for detecting a 287 or 387 FPU, I use the +infinity/-infinity test. On the first-generation 80287 these values were the same, but on 287XL/387 and comparable FPUs, sporting full IEEE 754 compatibility, +infinity is not same as -infinity.

When Intel designed the old 8087 core (which is also included in the 80287), IEEE 754 did not yet specify whether +inf should be considered equal to -inf or not. To be future-proof, Intel included both modes ("affine" and "projective") in that core. It defaults to "projective" after F(N)INIT, which means -inf == +inf. Later, IEEE decided that -inf should be considered unequal to +inf, this is the non-default "affine" mode of the 8087 core. In the 80386 core (which is also included in the 80287XL), support for the projective mode has been removed, so the 80387 is in affine mode after F(N)INIT. The "after F(N)INIT" part of this statement is important, because if you just perform the equality comparison test without resetting the 80287 before, you might find it in affine mode and detect it as 80387. As most FPU detection functions start with FNINIT, I expect that CHKCPU does not trip here.

Chkcpu wrote on 2022-12-17, 20:59:

Note that I only perform the infinity test when a 80286 or later CPU is detected, because I don’t know how an 8087 or 80187 would react on this test.

As explained above, a 8087 behaves exactly like the 80287 at this test. On the other hand, the 80187 contains the 80387 core. Originally, the 80186/80188 were intended to be paired with the original 8087 coprocessor. The 80187 is basically an 8087XL, but it does not support the 8-bit mode required to interoperate with an 80188, and is designed to support the 80186 only. I didn't research whether you could also operate an 8086 with an 80187, but in theory it shouldn't be a problem, as the bus protocol of the 8086 and 80186 is identical.

Chkcpu wrote on 2022-12-17, 20:59:

To finally answer your question, when an original 80386 or 386DX is paired with a first-generation 287, CHKCPU displays “386DX with 287 FPU”.

This is fine and an obvious result from the infinity test.

Chkcpu wrote on 2022-12-17, 20:59:

But when a 287XL or 387 is fitted, CHKCPU displays “386DX with 387 FPU”

And that's where my suggestion for the "perfect solution" applies to: Check the original value of ET. If it is 0 (32 bit), the FPU is a 387(DX). If it is 1 (16 bit), the FPU is a 287XL. You can easily distinguish that.

Jan, I'm sorry but there is a case where you need 16/32-bit buswidth detection to distinguish a 386DX paired with either a 287XL or a 387/387DX.
+infy/-infy check is just enough to detect a 386 to be paired with a 287 (without XL)

386DX with 287 FPU --> check --> (can be verified by +infy/-infy test; does not need ET checking)
386SX with 387SX FPU --> check (hypothetical 287 / 287XL possible but i haven't heard about a 386SX mainboard having a 287 socket)
386DX with 387 FPU --> may be improved to distinguish between 287XL and 387 / 387DX:
386DX with ET0 -> 387 or 387 DX (needs to analyze instruction timing)
386DX with ET1 -> +infy/-infy test => 287 <-> 287XL (on early 386 DX mainboards that have been from a time where no 387 existed) (387 SX possible but i haven't heard about a 386DX mainboard having a 387SX socket)

@mkarcher, @Disruptor, thanks for making the FPU / 386 ET bit picture complete.

I fully understand now that checking the original ET bit status can help to differentiate between a 287XL and a 387(DX) on those early 80386/386DX systems with both a 287 and 387 socket.

Yes, after flipping the ET bit for the buswidth test, my code restores the original CR0 state immediately. I learned these “best coding practices” early on. 😉

I will probably save further perfections to the FPU detection for the next CHKCPU update.
I’m now in the final stages of testing CHKCPU v1.27 (and CHKCPU32 v2.15) on my own systems. For CHKCPU this means running the tool also in Virtual mode and under Win9x in Protected mode. In both cases there shouldn’t be any crashes due Illegal Opcode Exceptions or General Protection Faults.
Due to the expanded 386/486 detection logic I had to use restricted instructions at more places and also put more bad opcode handlers in place to handle any exceptions. Memory managers like EMM386 will usually handle these exception transparently, however certain exceptions will cause Windows to kill the program, and the DOS box it is running in, before CHKCPU has a chance to handle the fault itself. So I put code in to bypass certain checks if CHKCPU is run under Windows.
Although this will make the tool less accurate when run under Windows, it should’t crash even if it is meant to run under DOS. 😉

Jan

Thank you all for your valuable input when beta testing this CHKCPU Retro update!

Final testing only showed one bug, incorrect L1 cache size detection on Cyrix 6x86(MX) CPUs and this bug is fixed.
This means the CHKCPU 25th anniversary ‘Retro’ update v1.27 is ready and is available for download from my website. 😀
I’ve put the link at the first message of this thread.
In the zip-file you’ll also find a CHKCPU.TXT file with full details about the program, and the complete changelog.

If you want to use the new CHKCPU from Phil’s Benchmark Pack menu, just copy the new CHKCPU.EXE to the \DOSBENCH\MARKS\CHKCPU folder and overwrite the old version.

Note that CHKCPU also has a Verbose mode that can give you additional information about a 486 or later CPU. Just type chkcpu /v to get the size(s) of the internal cache(s) and when the CPUID instruction is supported, you’ll see additional information about CPU features and Instruction set extensions.

An example on my K6-III+/500:

If you want this chatty display everytime in Phil’s Dosbench, open DOSBENCH.BAT in the DOSBENCH folder and look for the :chkcpu label. You should see these commands:

:chkcpu
cd marks
cd chkcpu
cls
chkcpu
pause
cd..
cd..
goto start

Then type /v behind the chkcpu command so that you get:

:chkcpu
cd marks
cd chkcpu
cls
chkcpu /v
pause
cd..
cd..
goto start

Close and Save DOSBENCH.BAT and you should see the verbose mode evertime you run CHKCPU in Dosbench.

Also with this new CHKCPU v1.27, report are still welcome. If you notice something that doesn’t look right, send a report or ask about it in this thread.

Jan

yay, nice work, will test later.

After releasing CHKCPU v1.27 final last December, a bug was brought to my attention.

In Real mode DOS all is fine, but when using a memory manager like EMM386, so the CPU is running in Virtual86 mode, this bug could hang the PC with an EMM386 error when CHKCPU was run on a 386 or 486 CPU without CPUID support.

I’ve fixed this bug and released an updated CHKCPU v1.27.1 today.
This CHKCPU ‘maintenance release’ is available from the link at the first message of this thread.

A special thank you to @CuPid for reporting this bug!
Jan