Yoghoo wrote on 2022-01-10, 10:24:

When I start hwinfo I get the following error: "Cannot run it under OS/2". After that I can only press OK which closes the program.

I am running it on DR-DOS 6.0 with Qemm 9.0 though. Funny thing is it's running hwinfo16 without problems. Also it works after a clean boot (so only DR-DOS 6.0). Lastly if I run it (with Qemm 9.0 etc) with the options "-v -d -r" it creates a log file without errors in it with all the information available in the program.

If you need more info let me know.

This is because HWiNFO detected it's running in V86 mode and due to that can't perform some checks. I'll try to fix the reporting in next build. Would be useful if you could attach the report+debug files produced.

Mumak wrote on 2022-01-10, 12:19:

Yoghoo wrote on 2022-01-10, 10:24:

When I start hwinfo I get the following error: "Cannot run it under OS/2". After that I can only press OK which closes the program.

I am running it on DR-DOS 6.0 with Qemm 9.0 though. Funny thing is it's running hwinfo16 without problems. Also it works after a clean boot (so only DR-DOS 6.0). Lastly if I run it (with Qemm 9.0 etc) with the options "-v -d -r" it creates a log file without errors in it with all the information available in the program.

If you need more info let me know.

This is because HWiNFO detected it's running in V86 mode and due to that can't perform some checks. I'll try to fix the reporting in next build. Would be useful if you could attach the report+debug files produced.

Thanks. See attachment from the above run with "-v -d -r" options (so with Qemm).

Yoghoo wrote on 2022-01-10, 13:14:

Mumak wrote on 2022-01-10, 12:19:

Yoghoo wrote on 2022-01-10, 10:24:

When I start hwinfo I get the following error: "Cannot run it under OS/2". After that I can only press OK which closes the program.

I am running it on DR-DOS 6.0 with Qemm 9.0 though. Funny thing is it's running hwinfo16 without problems. Also it works after a clean boot (so only DR-DOS 6.0). Lastly if I run it (with Qemm 9.0 etc) with the options "-v -d -r" it creates a log file without errors in it with all the information available in the program.

If you need more info let me know.

This is because HWiNFO detected it's running in V86 mode and due to that can't perform some checks. I'll try to fix the reporting in next build. Would be useful if you could attach the report+debug files produced.

Thanks. See attachment from the above run with "-v -d -r" options (so with Qemm).

Thanks!

Got another problem as well though. If I start clean (so no drivers etc) and go to Mainboard info it says: Fatal Error - Cannot continue. The pc hangs at this point and I have to hard reset it. Ctrl-alt-del etc don't work anymore.

Everything else is working in hwinfo. Only the mainboard info option gives problems. I tried to generate a logfile again (now with no drivers etc) but it also hangs and I need to hard reset the pc. No log file is created.

It's a 386/25 CPU on a Miata mainboard with an AMI bios (08/30/90). Don't know the mainboard type as I need to disassemble the pc to take a look at it which I don't have time for now.

Running with -d should produce Debug File that shows where it hung. Try to run with HIMEM.SYS only if that will work then.

Mumak wrote on 2022-01-10, 18:50:

Running with -d should produce Debug File that shows where it hung. Try to run with HIMEM.SYS only if that will work then.

Uploaded the debug file.

Also tried it with himem.sys and it works correctly then. But I had to copy it over from another pc because DR-DOS as well as Qemm don't have himem.sys.

Looks like Resetting the CPU to gather CPU ID is causing this. Without HIMEM.SYS HWiNFO needs to maintain A20M and that probably causes the issue.
The entire CPU Reset and gaining control before BIOS is a peculiar operation that sometimes doesn't work properly.

I recently finished a "286 build" based on a VLSI 200-series 286 chipset and am using an Evergreen 486 SuperChip upgrade unit, shown here Re: Evergreen 486 SuperChip - settings for DIP switch? The upgrade unit contains a Cyrix 486SLC2-50MP running at 66.6 MHz and a Cyrix 87SLC-33QP running at 33.3 MHz.

I downloaded HWiNFO 6.20 from the HWiNFO website and ran it on my "286". I ran hwinfo.exe -r -v but it was unable to create a log. The error shown on the screen was:

1Floating point error: Domain. 
2Abnormal program termination

I then proceeded to try hwinfo16 and ran hwinfo16.exe -r -v and have attached this log file.

hwinfo16 does not detect the process, co-processor, mainboard, or chipset correctly. It shows:

1Main processor: Unknown, ? MHz
2Math Co-Processor: Intel 8087, 46.1 MHz
3Mainboard Model: Unknown
4Mainboard Chipset: Unknown

feipoa wrote on 2022-02-25, 11:15:

I recently finished a "286 build" based on a VLSI 200-series 286 chipset and am using an Evergreen 486 SuperChip upgrade unit, s […]
Show full quote

I recently finished a "286 build" based on a VLSI 200-series 286 chipset and am using an Evergreen 486 SuperChip upgrade unit, shown here Re: Evergreen 486 SuperChip - settings for DIP switch? The upgrade unit contains a Cyrix 486SLC2-50MP running at 66.6 MHz and a Cyrix 87SLC-33QP running at 33.3 MHz.

I downloaded HWiNFO 6.20 from the HWiNFO website and ran it on my "286". I ran hwinfo.exe -r -v but it was unable to create a log. The error shown on the screen was:

Copy code to clipboard

1Floating point error: Domain. 
2Abnormal program termination

I then proceeded to try hwinfo16 and ran hwinfo16.exe -r -v and have attached this log file.

hwinfo16 does not detect the process, co-processor, mainboard, or chipset correctly. It shows:

Copy code to clipboard

1Main processor: Unknown, ? MHz
2Math Co-Processor: Intel 8087, 46.1 MHz
3Mainboard Model: Unknown
4Mainboard Chipset: Unknown

Thanks for the report. Please note that you used HWiNFO16 which is especially designed for 8086-286 ONLY and will never work properly on later systems.
Please use HWiNFO for DOS on that system. If there's a problem with HWiNFO for DOS too, please also run with the -d switch to create the HWINFO.DBG file.

Maybe I was not clear enough. I did use HWiNFO.EXE for DOS on this system. The error was:
Floating point error: Domain.
Abnormal program termination

I provided the HWiNFO16.EXE log because the regular HWiNFO didn't provide a log due to the above error.

I'll run debug later.

OK, got it 😀 I'll need to see the DBG file, that might give me some clues..

Here's the debug file. I ran hwinfo.exe -d -r -v

feipoa wrote on 2022-02-25, 12:37:

Here's the debug file. I ran hwinfo.exe -d -r -v

Thank you! I'm looking into this, but not 100% sure yet why this happens. Can you please run HWiNFO manual (without switches) and post a screenshot if it crashes on the main screen?
You could also try to disable Reset CPU Methods 1-3 if that will perhaps help.

Attached is the screenshot you requested. It shows the same error as the verbose mode.

I then checked one by one the CPU reset methods in the ini file. Method 1 or Method 2 cause a crash, while Method 3 is OK. Attached are the log and debug files from Method 3.

The processor is detected correctly: Cyrix Cx486SLC2, 66.6 MHz

The co-processor is detected incorrectly. It is showing a Cyrix FasMath 83D87 New, 17.6 MHz. The Cyrix Cx87SLC-33QP should be running at 33.3 MHz. The speed is determined by the FSB * 2. The Evergreen interposer uses a custom 2x PLL for the CPU and the FPU. The Cx486SLC2 has another onboard 2x PLL, thus 66.6 MHz.

EDIT: Also, HWiNFO reports VLB, but the system is ISA only. I don't beleive the VLSI 200 series chipsets had any support for VLB.

Thanks, this is interesting. It seems that the crash happening when Method 1 or 2 is enabled happens during normal floating-point math. So I assume when HWiNFO performs a soft-reset, some BIOS bug workarounds don't get applied or the FPU isn't re-initialized properly.
FPU clock is determined by measuring real FPU instruction throughput/latency. So are you sure it's running at 33 MHz and the 2x PLL works? Perhaps you can try to confirm using other FPU test/bench tools.

Mumak wrote on 2022-02-26, 08:18:

Thanks, this is interesting. It seems that the crash happening when Method 1 or 2 is enabled happens during normal floating-point math. So I assume when HWiNFO performs a soft-reset, some BIOS bug workarounds don't get applied or the FPU isn't re-initialized properly.
FPU clock is determined by measuring real FPU instruction throughput/latency. So are you sure it's running at 33 MHz and the 2x PLL works? Perhaps you can try to confirm using other FPU test/bench tools.

Although I have not probed the CPU and FPU on the Evergreen unit, I would be surprised if Evergreen only enabled clock doubling for the ALU and not the FPU. I ran some benchmarks using various configurations with Landmark v2. First is with a Harris CS80C286-16 and a Cyrix FasMath Cx-82S87-NP-SV co-processor.

And compared it with the Evergreen SLC unit.

Harris CS80C286-16 and a Cyrix FasMath Cx-82S87-NP-SV co-processor, both at 16.7 MHz
Landmark FPU = 24.03

Cyrix Cx486SLC2-66 and a Cyrix Cx87SLC-33, at their respective speeds
Landmark FPU = 45.35

The FPU results are about double with double the FPU frequency.

One may wonder... how much gain is the SLC at 2x providing to the FPU? Before I had the SLC2 soldered on, I had an ordinary SLC soldered on. With the SLC at 33 MHz, the Landmark FPU score was 41.20. So one may deduce that the SLC at 66 vs. 33 MHz, aids the Cx87SLC FPU by about 10%. You may also wonder, how much benefit does the SLC's L1 provide to the FPU? I ran Landmark with the SLC2-66's L1 disabled, and the FPU result was 39.5 (-10%). Adding these conditions in attempt to match that of the cacheless 286, we'd subtract 10% from 41.2 to approximate the SLC-33 without L1 and another 10% to approximate a SLC-16.7 (but FPU still at 33.3 MHz) and arrive at a simulated Landmark FPU score of 33.37. 33.37 isn't exactly double that of 24 from the 286, so it is hard to draw a conclusion. It may be that the SLC was really designed to run without L1 cache, and one cannot say there is a 1:1 relationship between the Harris 286 and a Cyrix SLC at the same frequency.

Unfortunately, there doesn't appear to be any documented DIP switch settings for this Evergreen unit. I suppose I could start flipping switches to see if any of them increase the FPU score, which might indicate that FPU clock doubling is disabled. I also tried to locate the datasheet for the Cx87SLC but couldn't locate it.

Well the problem here is that I'm not aware of any software method that would allow precise distinguish between some of the Cyrix FPU models, maybe it's not possible at all.
And if one doesn't know the exact model and how many clocks execution of certain FPU instructions take, it's not possible to report exact FPU clock here.
Do you maybe know if there's some documentation about the Cx87SLC? Is this closer to the 82S87, 83S87 or 83D87 or something else?

Others are also looking for the 87SLC datasheet. https://www.cpu-world.com/forum/viewtopic.php?t=31280

I'm speculating, but I bet the Cx87SLC has performance more similar to the 82S87 since the 83D87 has a wider data path. On a 386 with a DRx2-66, using a 33 MHz FasMath gets a Landmark v2 FPU score of around 218, which is way higher than the 45 w/SLC2-66 + 87SLC33. The FasMath 82S87 was supposed to be the fastest CPU for a 286. It is also quite rare.

Will you be needing any further testing done with this CPU/FPU combination, e.g. for FPU type, speed, incorrect VLB determination, etc...?

Is there a means to have the HWiNFO automatically alter the CPU reset method (1, 2, or 3) based on the type of CPU that is installed? If not, the user will need to manually check/uncheck each of them to find the one which works. However, I think most users won't know or won't bother and prefer to move on to a different software suite.

feipoa wrote on 2022-03-03, 08:35:

Will you be needing any further testing done with this CPU/FPU combination, e.g. for FPU type, speed, incorrect VLB determination, etc...?

Is there a means to have the HWiNFO automatically alter the CPU reset method (1, 2, or 3) based on the type of CPU that is installed? If not, the user will need to manually check/uncheck each of them to find the one which works. However, I think most users won't know or won't bother and prefer to move on to a different software suite.

Thanks, but currently I have no idea how to properly identify this FPU. No documentation seems to be available and it's also quite likely that it's not possible to detect this model using software.

Regarding the CPU Reset methods (used to obtain CPU ID on CPUs not supporting the CPUID instruction) I'm afraid it's not possible to predict in advance if/which one will or will not work on a particular system. I believe the result doesn't depend on the CPU, rather the mainboard/BIOS and configuration options.