Mumak> OK. Sounds like you want any hardware tested.

Which flavour do you prefer be tested on these older systems? On fosshub.com I see the following for download:

HWiNFO Beta
HWiNFO Installer
HWiNFO Portable (I assume older than Beta)
HWiNFO Portable - PAF Format

If given the choice of Win9x, NT4, W2K, or XP, which OS do you prefer we test on?

For the DOS version, I'll use what was posted in the forum.

I should be able to start this evening once the rest of the family has gone to bed.

feipoa wrote on 2020-04-14, 01:33:

Mumak> OK. Sounds like you want any hardware tested. […]
Show full quote

Mumak> OK. Sounds like you want any hardware tested.

Which flavour do you prefer be tested on these older systems? On fosshub.com I see the following for download:

HWiNFO Beta
HWiNFO Installer
HWiNFO Portable (I assume older than Beta)
HWiNFO Portable - PAF Format

If given the choice of Win9x, NT4, W2K, or XP, which OS do you prefer we test on?

For the DOS version, I'll use what was posted in the forum.

I should be able to start this evening once the rest of the family has gone to bed.

HWiNFO32/64 v6.25-4135 Beta is currently the latest build, so that one would be best.
As for OS, later versions (W2k+) can provide more information, but if your system is capable to handle Win9x only, then it's OK as well.
For DOS the one posted here (6.0.5) is the latest as of now.
Thanks in advance!

I ran Hwinfo v6.25-4135 from within Windows 95c on a Cyrix 5x86-133/4x. The motherboard is a DTK PKM-0033S. I have attached the report and debug files. Some observations,

1) Multi-thread is selected by default in the Benchmark menu. If it is left selected, the CPU score is either N/A or abnormally low (386 points in my second test). I must force single-thread for the score to be appropriate. For this system, CPU=1283, FPU=1285. On the first run, the memory transfer rate was 47 MB/s, but on two later runs it was 34 MB/s, then 36 MB/s.

2) Refer to the attached screenshots for possible missing information.

3) report and debug

feipoa wrote on 2020-04-14, 08:43:

I ran Hwinfo v6.25-4135 from within Windows 95c on a Cyrix 5x86-133/4x. The motherboard is a DTK PKM-0033S. I have attached the […]
Show full quote

I ran Hwinfo v6.25-4135 from within Windows 95c on a Cyrix 5x86-133/4x. The motherboard is a DTK PKM-0033S. I have attached the report and debug files. Some observations,

1) Multi-thread is selected by default in the Benchmark menu. If it is left selected, the CPU score is either N/A or abnormally low (386 points in my second test). I must force single-thread for the score to be appropriate. For this system, CPU=1283, FPU=1285. On the first run, the memory transfer rate was 47 MB/s, but on two later runs it was 34 MB/s, then 36 MB/s.

2) Refer to the attached screenshots for possible missing information.
HWINFO_6.25-4135_on_Cx5x86-133-4x_page2.jpg
HWINFO_6.25-4135_on_Cx5x86-133-4x_page1.jpg

3) report and debug
Report_and_Debug_for_Cyrix_5x86-133-4x.rar

Thanks! Not so bad for the first attempt. CPU detection work well, which is important. I will adjust a few things like detection of the mainboard name, network adapter, etc..

Looks like NT4 wasn't as kind to HWiNFO as Win95 was. BSOD when analysing hardware during app start.

Debug report:

feipoa wrote on 2020-04-14, 09:56:

Looks like NT4 wasn't as kind to HWiNFO as Win95 was. BSOD when analysing hardware during app start. HWINFO_6.25-4135_on_Cx5x86- […]
Show full quote

Looks like NT4 wasn't as kind to HWiNFO as Win95 was. BSOD when analysing hardware during app start.
HWINFO_6.25-4135_on_Cx5x86-133-4x_NT4_BSOD.jpg

Debug report:
Report_and_Debug_for_Cyrix_5x86-133-4x_NT4_BSOD.rar

Thanks. I think I found this bug, going to fix it now.

HWiNFO v6.25_4137 ran OK on NT4 this time. I see there's quite a bit more information under ports and other headings now.

I was wondering about your min/max FSB listings though - where they come from and why they are set as such? See comments in photo.

The CPU bench score is not available t the first time running for some reason.

Also the FPU score is substantially lower when running NT4 compared to Win95c. Why is this? But if you look at the screenshot from above, the FPU result was the same as the CPU result. I was also wondering why the disk drive benchmark is greyed out.

Attached is the report and debug.

Misc. Notes : I think DTK PKM-0033S and Gemlight GMB-486SPS are the same motherboards.

feipoa wrote on 2020-04-15, 07:46:

HWiNFO v6.25_4137 ran OK on NT4 this time. I see there's quite a bit more information under ports and other headings now. Lots_ […]
Show full quote

HWiNFO v6.25_4137 ran OK on NT4 this time. I see there's quite a bit more information under ports and other headings now.
Lots_more_information_now.png

I was wondering about your min/max FSB listings though - where they come from and why they are set as such? See comments in photo.
Max_min_FSB_info.png

The CPU bench score is not available t the first time running for some reason.
CPU_Bench_NA.png

Also the FPU score is substantially lower when running NT4 compared to Win95c. Why is this? But if you look at the screenshot from above, the FPU result was the same as the CPU result. I was also wondering why the disk drive benchmark is greyed out.
Disk_drive_bench_greyed_out.png

Attached is the report and debug.Report_and_Debug_for_Cyrix_5x86-133-4x_NT4.rar

Misc. Notes : I think DTK PKM-0033S and Gemlight GMB-486SPS are the same motherboards.

Thanks!
This provides me a lot of useful information that should help me to solve the problem in DOS version too.
The FSB information shown is deduced from actual clock measured / ratio. It is quite off because the measurement can't be precise enough on such systems. I guess similar applies to the benchmark score, but I will have a look at that at sometime later once I resolve the more serious issues..
Could you please run HWiNFO32 twice on the machine and attach a new DBG file from the 2nd run? This is because during the first run HWiNFO enables CPUID instruction and I assume this is somehow causing an issue in the DOS version..

Here it is.

feipoa wrote on 2020-04-15, 08:34:

Here it is.
Report_and_Debug_for_Cyrix_5x86-133-4x_NT4_2nd_run.rar

Thanks. Weird, but if this is the DBG from 2nd run it would indicate the CPUID can't be enabled on this CPU. I didn't expect this, have you perhaps tried to do this?

No I didn't edit anything. CPUID wasn't properly implemented on the Cyrix/IBM 5x86 series of CPUs.

feipoa wrote on 2020-04-15, 08:53:

No I didn't edit anything. CPUID wasn't properly implemented on the Cyrix/IBM 5x86 series of CPUs.

Yeah, but question is what exactly that means 😁 If it doesn't work at all or can cause an issue.. Would be much easier if I'd have such a system here...
Would you have time to run just another build on the NT system?

From the Cyrix BIOS Writers Guide

1The second detection method utilizes the CPUID instruction. The CPUID instruction is not available until Stepping 1 of the 5x86 CPU. When available, the CPUID instruction is disabled at reset and will not execute until it is enabled through the configuration registers. The following paragraphs describe each method. 
2
3Standard CPU Identification Method System BIOS can determine if a 5x86 microprocessor exists by first determining if a Cyrix CPU exists. If a Cyrix CPU exists, the DIRs can be read to identify the type of Cyrix CPU. Previous versions of Cyrix CPUs (such as early versions of the Cx486SLC and Cx486DLC) did not contain the DIRs. However, all CPUs currently in production contain DIRs.
4
5
63.2 CPU Identification Using CPUID Instruction
7The CPUID instruction will not be available until Stepping 1 of the device. Stepping 1 is indicated by DIR1=0001xxxx. This method utilizes the 5x86 CPU Identification (CPUID) instruction. The ability to write and then read bit 21 of the EFLAG register indicates that the CPU supports the CPUID instruction. The CPUID instruction and the ability to write to bit 21 of the EFLAG register are disabled at reset. See section 4.2.4 for details on enabling the CPUID instruction. The CPUID instruction, opcode 0FA2h, provides information to identify Cyrix as the vendor and to indicate the revision and stepping of the CPU being tested.
8
9For the CPUID instruction, the EAX register is loaded with a value to indicate the information that should be returned by the instruction. Following execution of the CPUID instruction with a zero value in EAX, the EAX, EBX, ECX, and EDX registers contain information resulting from the pseudocode shown in Figure 3-1. The EAX register contains the highest input value understood by the CPUID instruction, which is “1” for the 5x86 CPU. The EBX, ECX, and EDX registers contain the vendor identification string “CyrixInstead”. Following execution of the CPUID instruction with an input value of one loaded into the EAX register, EAX(7-0) will contain the same value as DIR0, and EAX(15-8) will contain 04h. Bit 0 in the EDX register indicates if there is an FPU on-chip. 
10
11
124.2.4 Configuration Control Register 4 (CCR4)
13Bit 7:
14If set, this bit enables writing to bit 21 of the EFLAG register (indicating that the CPU supports the CPUID instruction) and the CPUID instruction will execute normally. See Paragraph 4.5. If clear, bit 21 of the EFLAG register is not writable and the CPUID instruction is an invalid opcode. This bit is only available on Stepping 1 and later versions of the 5x86 CPU. The CPUID instruction is disabled on all prior devices.

However, even with Stepping 1 CPUs, I think CPUIDEN was also disabled - I'd have to check again. But I know I tried to enable it and run some DOS program which needs CPUID, and the program crashed or reported no CPUID.

Yes, I have another half hour.

Also, if you take a look at the Cyrix CPU Detection Guide, you'll see that the 5x86 doesn't even support the standard CPUID functions.

feipoa wrote on 2020-04-15, 09:03:

From the Cyrix BIOS Writers Guide […]
Show full quote

From the Cyrix BIOS Writers Guide

Copy code to clipboard

1The second detection method utilizes the CPUID instruction. The CPUID instruction is not available until Stepping 1 of the 5x86 CPU. When available, the CPUID instruction is disabled at reset and will not execute until it is enabled through the configuration registers. The following paragraphs describe each method. 
2
3Standard CPU Identification Method System BIOS can determine if a 5x86 microprocessor exists by first determining if a Cyrix CPU exists. If a Cyrix CPU exists, the DIRs can be read to identify the type of Cyrix CPU. Previous versions of Cyrix CPUs (such as early versions of the Cx486SLC and Cx486DLC) did not contain the DIRs. However, all CPUs currently in production contain DIRs.
4
5
63.2 CPU Identification Using CPUID Instruction
7The CPUID instruction will not be available until Stepping 1 of the device. Stepping 1 is indicated by DIR1=0001xxxx. This method utilizes the 5x86 CPU Identification (CPUID) instruction. The ability to write and then read bit 21 of the EFLAG register indicates that the CPU supports the CPUID instruction. The CPUID instruction and the ability to write to bit 21 of the EFLAG register are disabled at reset. See section 4.2.4 for details on enabling the CPUID instruction. The CPUID instruction, opcode 0FA2h, provides information to identify Cyrix as the vendor and to indicate the revision and stepping of the CPU being tested.
8
9For the CPUID instruction, the EAX register is loaded with a value to indicate the information that should be returned by the instruction. Following execution of the CPUID instruction with a zero value in EAX, the EAX, EBX, ECX, and EDX registers contain information resulting from the pseudocode shown in Figure 3-1. The EAX register contains the highest input value understood by the CPUID instruction, which is “1” for the 5x86 CPU. The EBX, ECX, and EDX registers contain the vendor identification string “CyrixInstead”. Following execution of the CPUID instruction with an input value of one loaded into the EAX register, EAX(7-0) will contain the same value as DIR0, and EAX(15-8) will contain 04h. Bit 0 in the EDX register indicates if there is an FPU on-chip. 
10
11
124.2.4 Configuration Control Register 4 (CCR4)
13Bit 7:
14If set, this bit enables writing to bit 21 of the EFLAG register (indicating that the CPU supports the CPUID instruction) and the CPUID instruction will execute normally. See Paragraph 4.5. If clear, bit 21 of the EFLAG register is not writable and the CPUID instruction is an invalid opcode. This bit is only available on Stepping 1 and later versions of the 5x86 CPU. The CPUID instruction is disabled on all prior devices.

However, even with Stepping 1 CPUs, I think CPUIDEN was also disabled - I'd have to check again. But I know I tried to enable it and run some DOS program which needs CPUID, and the program crashed or reported no CPUID.

Yes, I have another half hour.

Hmm, that might explain something, perhaps that's the reason why it crashes in the DOS version...
Here just another build for the NT: www.hwinfo.com/beta/hwi32_625_4138.zip
In 3 minutes I will also post a new build for DOS test - I will remove enabling CPUID there to see if that's the reason.

OK, so take the report/debug from the second run again?

If Cyrix CPUID is something that interests you, I can pull out a stepping 1 chip at some point. Have you tried enabling the CPUID register?

feipoa wrote on 2020-04-15, 09:14:

OK, so take the report/debug from the second run again?

If Cyrix CPUID is something that interests you, I can pull out a stepping 1 chip at some point. Have you tried enabling the CPUID register?

1st run is OK with this build, no need to run twice now.
Yes, I try to enable CPUID (via CCR4 as per the BIOS guide) and then check back if it worked.. But perhaps this is what is causing the problem in DOS version, have posted a new build without this in the other thread.

Attached.

Mumak wrote on 2020-04-15, 09:19:

Yes, I try to enable CPUID (via CCR4 as per the BIOS guide) and then check back if it worked.. But perhaps this is what is causing the problem in DOS version, have posted a new build without this in the other thread.

But wouldn't the previous user of the Cyrix 5x86-100 have reported an issue with this already?

feipoa wrote on 2020-04-15, 09:27:

Mumak wrote on 2020-04-15, 09:19:

Yes, I try to enable CPUID (via CCR4 as per the BIOS guide) and then check back if it worked.. But perhaps this is what is causing the problem in DOS version, have posted a new build without this in the other thread.

But wouldn't the previous user of the Cyrix 5x86-100 have reported an issue with this already?

That was quite long ago, perhaps he had a different part..
Anyway, from the latest DBG file:

1DIR0=2C, DIR1=5
2Cx CPUID enable
3Cx CPUID not enabled

That means CPUID can't be enabled here.
Let's see what happens in the new DOS version..