Hola señores!

I've used the win9x (ver 1.01.0 - nvember 2019) on win98se (fresh install) version with a Cyrix MediaGx 200GP and it reports the FSB changing from ≃20 to 33.44 mhz and all odd figures in between (19.84, 22.22, 24.24 ...).
Frequency varies accoridng to the multiplier which stays at 6x (correct).

Motherboard is a ST-Mgxm with Cx5520 chipset.

CHiLL72 wrote on 2020-05-09, 17:08:

CuPid wrote on 2020-05-09, 16:24:

CHiLL72 wrote on 2020-05-08, 20:05:

This latest version still has a bug that I noticed on the Win9x 1.01 version on your website: the first time I run it on Windows 98SE on my ASUS CUBX-E Pentium III system, it shows Vcore on the first tab. If I close and then start CPU-Z again, Vcore is not displayed anymore.

This is not good sign. Could you please save a TXT report the 1st time and another one the second time and post them ?
I guess cpuz does not show vcore again until a reboot ?

Yes, that is correct, only after a reboot Vcore is shown again. I will save and post the report later.

Strangely enough, I cannot reproduce the problem with the latest version anymore... It did happen with version 1.01, but after closing that, running version 1.03 again, closing that and starting 1.01, Vcore did appear... Go figure.
I did save the reports however. 2nd run of version 1.01 did not show Vcore.

BTW, the only change I made to the computer in the meantime was change the battery, as the CMOS clock would not run when the system was turned off, so time and date were off.

CHiLL72 wrote on 2020-05-10, 10:35:

Strangely enough, I cannot reproduce the problem with the latest version anymore... It did happen with version 1.01, but after closing that, running version 1.03 again, closing that and starting 1.01, Vcore did appear... Go figure.
I did save the reports however. 2nd run of version 1.01 did not show Vcore.

BTW, the only change I made to the computer in the meantime was change the battery, as the CMOS clock would not run when the system was turned off, so time and date were off.

Thanks for the test.
As I suspected the version 1.01 locked the smbus and therefore the 2nd run showed no SPD and no sensor data. That was indeed fixed in the meantime.

Edit : I did not pay attention to your CPU, nice (and rare) model !

Nexxen wrote on 2020-05-09, 22:46:

Hola señores! […]
Show full quote

Hola señores!

I've used the win9x (ver 1.01.0 - nvember 2019) on win98se (fresh install) version with a Cyrix MediaGx 200GP and it reports the FSB changing from ≃20 to 33.44 mhz and all odd figures in between (19.84, 22.22, 24.24 ...).
Frequency varies accoridng to the multiplier which stays at 6x (correct).

Motherboard is a ST-Mgxm with Cx5520 chipset.

Hola ! and thanks for your report.
This is indeed very strange. I have a look and let you know.

CuPid wrote on 2020-05-10, 19:01:

As I suspected the version 1.01 locked the smbus and therefore the 2nd run showed no SPD and no sensor data. That was indeed fixed in the meantime.

I suspect it's not an SMBus lockup and the issue could well be that CPUZ either does not have code to drive the SMBus Multiplexor or the code is incorrect. Note how the SPD is on SMBus #1 and I don't think there is SPD data in any of the CPUZ save files.

1[SMB Bus] <- SIV32L - System Information Viewer V5.48 Beta-08 ASUS-CUBX-E::Chiel
2
3#  Device Name    |Bus-Numb-Fun|  Port  Multiplexing  RM  GB  SO  CO  Vendor-Dev-Sub_OEM-Rev  [Y]INUSE Wait 0 of 801 ms ASUS CUBX-E
40  ASUS CUBX SMB  [ 0 - 04 - 3 ]  E800  [Y][_]#0      BF              8086-7113-00000000-02   Intel 82371EB PIIX4E Power Management Controller
51  ASUS CUBX MUX  [ 0 - 04 - 0 ]  E437  [Y][_]#1      18      67  00  8086-7110-00000000-02   Intel 82371EB PIIX4E ISA Bridge
6
7Slave   SMBus Device    Host     Peak  Data  Hex     Data
8Device  Description     Status   Time  Size  Offset  00  01  02  03  04  05  06  07  08  09  0A  0B  0C  0D  0E  0F
9
10|0_10|                  04         59  0000
11...
12[0_2D]  AS99127 (ASUS)  02        221  0010  00      B6  B7  5D  5E  B6  CB  05  CD  A7  F8  A5  AC  8C  68  54  F8
13                                       0003  40                                      2D  20                      5C
14                                       0004  50                                      31  8F              48  E2
15                                       0003  70                                              00  81  05
16...
17[0_2F]                  02        221  0010  00      __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __
18...
19[0_48]                  08        214  0001  00      __
20[0_49]                  08        277  0009  00      27  ..  5C  64  27  ..  5C  64  26
21|0_4A|                  04        113  0000
22...
23|0_69|  <excluded>      00          0  0000
24...
25|0_7F|                  04         62  0000
26|1_10|                  04         61  0000
27...
28[1_30]                  02        221  0010  00      __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __
29[1_31]                  02        221  0010  00      __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __
30...
31[1_50]  DIMM SPD Data   02        221  0010  00      80  08  04  0C  0A  02  40  ..  01  75  54  ..  80  08  ..  01
32[1_51]  DIMM SPD Data   02        221  0010  00      80  08  04  0C  0A  02  40  ..  01  75  54  ..  80  08  ..  01
33...
34[1_60]                  02        221  0010  00      __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __
35[1_61]                  02        221  0010  00      __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __
36[1_62]                  02        221  0010  00      __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __
37[1_63]                  02        222  0010  00      __  __  __  __  __  __  __  __  __  __  __  __  __  __  __  __
38...
39|1_7F|                  04         63  0000
40
41Total of 2 SMBuses and 12 SMBus Devices in 13.264 seconds (0.757 KBps). Slaves Probed 223. [Scan Range]0_10 to 1_80. [.. -> 00 : __ -> FF]
42
43[  OK ]  [ Copy]   [Windows]  [Machine]  [ DIMMs]  [Sensors]  [USB Bus]  [ SPD ]   [PMB Bus]  [Volumes]  [SMB Bus]  [PCI Bus]   [ALL Dev]

CuPid wrote on 2020-04-17, 11:36:

feipoa wrote on 2020-04-17, 10:44:

Is CPU-Z able to display the graphic card information for VLB cards? Everything in the Graphics tab is greyed out.

No, I don't have the smallest idea about how to detect VLB or ISA cards.

Probably they can be detected by reading VideoBIOS. Most of cards displaying their name on startup time, and the name is hardcoded into ROM. So to get the card name a finding of the hardcoded string in the VideoBIOS dump should be enough. However, detecting of VRAM type, clocks, etc seems to be vendor-specific. Or driver-specific. Some drivers are displaying information in system Control Panel, so probably there an standardized API is exists.

OAK OTI 077 also showed VRAM size for me (on 386 and Microsoft's driver from Win95 CD).

But other drivers does not doing such. Some info like GPU type and amount of VRAM can be retrieved through VESA calls. But this needs an DOS program (like SciTech Display Doctor) or an VxD driver.

i got CPU-Z scores for Pentium Pro 200 (66x3) and 233 (overclock, 66x3.5), results were from a Windows NT enviorment (Windows 2000 Pro). Will post screenshots later (got them, but is in another computer and only have the scores anotated right now)

Pentium Pro 200:
CPU - 322,2
FPU - 1289,7

Pentium Pro 233 OC:
CPU - 376,4
FPU - 1504,2

System specs:
Pentium Pro 200-233
128 MB EDO
Intel VS440FX
Geforce FX 5500 PCI
20 GB HDD
Windows 2000 SP4

I tried it and now it displays L1 Cache properly. It doesn't show the lithography of the CPU, though.
Also, would it be possible to show what kind of board cache is installed on the board (Asynch, Pipeline Burst etc.)?
Oh, and sorry for taking so long.

red-ray wrote on 2020-05-12, 10:30:

I suspect it's not an SMBus lockup and the issue could well be that CPUZ either does not have code to drive the SMBus Multiplexor or the code is incorrect. Note how the SPD is on SMBus #1 and I don't think there is SPD data in any of the CPUZ save files.

hi Ray. There is a mux indeed, but the problem was not related to the mux because the LPCIO only appeared at the 1st run with the previous version, and all subsequent smbus calls failed.

> ATauenis : I'm currently working on that, at least on the most popular video card models.

> Carlos S.M. : thanks for the scores, I add them in my list.

> TechieDude : thanks. Yes I think it is possible to read back this information, at least on the 430TX.

I can also test it on 430FX if you need me to.

One weird thing I've run into with an Epox EP-58MVP3C-M board is that CPU-Z can't tell the multiplier setting and FSB for either my K6-3D, or my Pentiums. Yet, those values when using a Cyrix 6x86 PR166+ get detected completely. That said, I've found this board has some weird behaviors with most CPUs when it comes to the jumper settings. On a lot of them, setting the jumper settings per the silkscreen results in frequencies that would not be correct at those settings, and it just so happens that with the Cyrix, it behaves as I would expect it. That might be a bug with my board, or its BIOS, so I'm not necessarily convinced this is a problem with CPU-Z VE.

It has however let me to notice that Vintage Edition validations without the FSB and multiplier still get marked as "Validated" on the valid.x86.fr site, but internally seem to still be classed as rejected. Namely, I shared the results to someone in a Slack chat, where the preview still said "Rejected dump" for all validations other than the Cyrix. Also, my Pentium MMX 233 running at 301MHz should have been in the top 15 if it was actually validated, which it however is not, thus it doesn't show up there. Is this intentional? I understand if the Vintage Edition demands for validation are more lax due to the fact that multiplier and FSB settings on older boards can't always be read, but in that case, there should be a separate validation classification for vintage CPUs to avoid confusion.

Validations in question:
Pentium MMX 233 @ 301MHz | Pentium 120 | AMD K6-3D 266 | SGS-Thompson Cyrix PR166+

Daniël Oosterhuis wrote on 2020-05-17, 10:12:

One weird thing I've run into with an Epox EP-58MVP3C-M board is that CPU-Z can't tell the multiplier setting and FSB for either my K6-3D.

Those two models have no register to read the multiplier, and it is not possible to guess without ambiguity (a Pentium @ 100 MHz for example can be 1.5 x 66 or a 2x50). On the contrary the Cyrix reports its current multiplier.

Daniël Oosterhuis wrote on 2020-05-17, 10:12:

It has however let me to notice that Vintage Edition validations without the FSB and multiplier still get marked as "Validated" on the valid.x86.fr site, but internally seem to still be classed as rejected. Namely, I shared the results to someone in a Slack chat, where the preview still said "Rejected dump" for all validations other than the Cyrix. Also, my Pentium MMX 233 running at 301MHz should have been in the top 15 if it was actually validated, which it however is not, thus it doesn't show up there. Is this intentional? I understand if the Vintage Edition demands for validation are more lax due to the fact that multiplier and FSB settings on older boards can't always be read, but in that case, there should be a separate validation classification for vintage CPUs to avoid confusion.

Yes it seems to be a bug on the validation side, the classic version does not allow an empty BCLK, but the VE does, in theory. It needs a check anyway.

Attached is the report for an IBM 486BL3 running at 75 MHz. Although L1 is enabled, the benchmark result is abnormally low so I'm going to play around with CPU register settings.

CPU-Z is incorrectly reporting the Package as Socket 168 PGA. The IBM BL3 is QFP only, but it is currently on an adapter that interfaces to the motherboard's PGA-132.

CPU-Z is incorrectly reporting the core speed. It is running at 75 MHz not 66.09 MHz.

CPU-Z is incorrectly reporting the L1 cache size. The BL3 has 16 KB, not 8 KB.

I cannot figure out why the CPU-Z benchmark results are abnormally low. What is further surprising is that when I disable L1 cache, the benchmark results increase, e.g. from 11.0 to 12.6 ALU and from 42.1 to 35.5 FPU. The cache is definitely enabled in DOS because cachechk shows a step at the 16 KB boundary and the DOOM result is substantially better with L1 on.

EDIT: I have resolved this issue. The IBM BL3 can only cache up to 16 MB of RAM and I had 32 MB installed. Removing 16 MB of RAM put the benchmarks numbers back into the expected range. CPU = 43.5 and FPU = 55.8 for IBM 486BL3-75.

Thanks feipoa.

The BL3-75 should indeed score around 40 in the ALU test.
The problem could be related to the reference timer used in the bench, you can check if timers are OK with the "Tools" -> "Timers" feature, and start a counting and see what is happening.

The detection of the BL3 is a real struggle under windows, because it relies on the support of MSRs registers and an exception handling mechanism at the kernel level that is not supported by win9x.

I've made two versions for you :

- that one does force the MSR reading, and then should report the BL3. On anything else than a BL3, it will generate a blue screen. But at least it will allow to check if the routines are correct, and maybe the bench result will benefit of the correct clock speed : http://download.cpuid.com/betas/cpuz_w9x_bl3.zip

- that one is a normal version with logging. Please unzip it and run it. It will create a "logs" folder at the same level as the exe, can you please send me back its content ? http://download.cpuid.com/betas/cpuz_w9x_dbg.zip

I'll run these tomorrow. I've been staying up too late and its showing in my health.

You have attached two different version of CPU-Z. You want me to run both and send the logs?

Issue with CPU-Z bench score has been resolved. I edited my post, but I think you missed it. The biggest drawback of the IBM 486BL3 is the inability to cache more than 16 MB.

feipoa wrote on 2020-05-20, 10:01:

You have attached two different version of CPU-Z. You want me to run both and send the logs?

Only the dbg version will generate a log file. For the other version, if everything is OK no need to save anything.
BTW, the versions include a video BIOS dump feature (in Tools), a report would be useful for the ISA/VLB video cards detection.
Thanks !

feipoa wrote on 2020-05-20, 10:01:

Issue with CPU-Z bench score has been resolved. I edited my post, but I think you missed it. The biggest drawback of the IBM 486BL3 is the inability to cache more than 16 MB.

OK, the score is in the expected range.

I've attached the report and Video BIOS dump for the special _bl3 version of CPU-Z. It seems to report correctly now, but isn't very useful unless you can integrate it into the normal version of CPU-Z.

I've also attached the debug file from the log folder. That version still shows the incorrect CPU.

Thanks feipoa.
As you pointed this is not very useful, unless I find a way to read the MSR without harm.
My idea is to run the MSR read instruction at the user level (and not at the kernel level) and read back the exception.
If the CPU does not support the MSR read instruction, it should report STATUS_ILLEGAL_INSTRUCTION. If it does, like the IBM 486, I expect to get STATUS_PRIVILEGED_INSTRUCTION, meaning that the instruction is supported, but can"t run in user mode. At that point I can run the instruction at the kernel level w/o risk because I know it is supported.
But in your report, the error code is STATUS_ACCESS_VIOLATION.

Oh no. Is there any instruction you can send to the CPU that only an IBM 486BL3 will return a unique response?