There was only two revisions of this chip. Stepping 0, Revision 5 and Stepping 1, Revision 3. Oddly enough, Stepping 0 Revision 5 chips all have later datecodes compared to Stepping 1, Revision 3 chips. The benefit of Stepping 1, Revision 3 chips is that branch prediction works in Windows, while it only seems to work in DOS with Stepping 0, Revision 5 chips.

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

There was only two revisions of this chip. Stepping 0, Revision 5 and Stepping 1, Revision 3. Oddly enough, Stepping 0 Revision 5 chips all have later datecodes compared to Stepping 1, Revision 3 chips. The benefit of Stepping 1, Revision 3 chips is that branch prediction works in Windows, while it only seems to work in DOS with Stepping 0, Revision 5 chips.

That's interesting, I didn't know that.. And starting to wonder whether the crash in DOS isn't related to some erratum in the CPU...

Hi

Gigabyte AM/S rev. 2.20 has been tested using HWiNFO 6.05 with following CPUs:
1. AMD Am5x86DX5-133V16BHC (Kingston Turbochip 133, with L1 Cache WT locked)
2. AMD Am486DX4-100V16BGC
3. AMD Am486DX4-100NV8T
4. AMD Am486DX2-80N
5. Intel i486SX-25
6. Intel i486DX-50
7. Intel i486DX2-66 (P24D)
8. Cyrix Cx486DX2-v66GP
9. ST486DX2-66GS
10. UMC U5S-Super40

Issues found:
• Program crashes if CPU detection method 1 is used, and CPU does not support CPUID instruction. All tests have been done using CPU detection method 2
• Program crashes when trying to save report file, if BIOS flash detection is enabled. When it’s enabled, and you do not try to “check” BIOS details, and do not generate a report, it is okay then. (P.S. this board does have a flash BIOS – SST 29EE010/5v chip)
• Intel i486SX-25 is detected as i486DX-25 chip
• Not an issue actually, but it would be great, if there would be possibility, to have an option to be asked for a log file name. It would enable to include program to autoexec.bat file, and would eliminate the need of manually starting HWINFO (yes, I know, I’m lazy).

Regards

phantom_pl wrote on 2020-04-15, 13:27:

Hi […]
Show full quote

Hi

Gigabyte AM/S rev. 2.20 has been tested using HWiNFO 6.05 with following CPUs:
1. AMD Am5x86DX5-133V16BHC (Kingston Turbochip 133, with L1 Cache WT locked)
2. AMD Am486DX4-100V16BGC
3. AMD Am486DX4-100NV8T
4. AMD Am486DX2-80N
5. Intel i486SX-25
6. Intel i486DX-50
7. Intel i486DX2-66 (P24D)
8. Cyrix Cx486DX2-v66GP
9. ST486DX2-66GS
10. UMC U5S-Super40

Issues found:
• Program crashes if CPU detection method 1 is used, and CPU does not support CPUID instruction. All tests have been done using CPU detection method 2
• Program crashes when trying to save report file, if BIOS flash detection is enabled. When it’s enabled, and you do not try to “check” BIOS details, and do not generate a report, it is okay then. (P.S. this board does have a flash BIOS – SST 29EE010/5v chip)
• Intel i486SX-25 is detected as i486DX-25 chip
• Not an issue actually, but it would be great, if there would be possibility, to have an option to be asked for a log file name. It would enable to include program to autoexec.bat file, and would eliminate the need of manually starting HWINFO (yes, I know, I’m lazy).

Regards

Wow, thanks for the extensive report ! Now I need time to analyze it all 😁
Regarding the issues you found:
1. CPU Reset Methods - this is a known problematic part, unfortunately the only way how to obtain the CPU ID value in DX register after reset when CPUID instruction is not supported. On some systems some of these methods unfortunately don't work and since these methods do quite crazy things (catch the execution after a reset before the BIOS gets control and attempt to restore everything back), I haven't been able to determine which systems have problems and why exactly yet.
2. Flash detection is not reliable on several systems, this is due to the nature how it works and the reason why it's disabled by default.
3. You can specify the log filename as argument, ex. HWINFO -r MYTEST.LOG

486SX can be distinguished from 486DX only by CPU ID value AFAIK. And since the reset methods didn't work to obtain the ID, it wasn't correctly identified.

ad3. I guess I wasn't precise enough. I know that I can specify filename after - r switch, but this is not, that I was thinking about. What I was thinking of is another parameter (-p for example), after using which, program would asked to enter log filename BEFORE running the tests. What would it do?, well that would enable me to include hwinfo line in autoexec. bat file, and just switch CPU's, and I wouldn't have to do anything more, because every time HWiNFO (autostarted by autoexec) would kindly ask me, how would I like to name logfile😁

Mumak wrote on 2020-04-15, 14:23:

486SX can be distinguished from 486DX only by CPU ID value AFAIK. And since the reset methods didn't work to obtain the ID, it wasn't correctly identified.

I thought, that such old CPU does not support CPU ID?

phantom_pl wrote on 2020-04-15, 15:31:

Mumak wrote on 2020-04-15, 14:23:

486SX can be distinguished from 486DX only by CPU ID value AFAIK. And since the reset methods didn't work to obtain the ID, it wasn't correctly identified.

I thought, that such old CPU does not support CPU ID?

They don't support the CPUID instruction. But all CPUs since 386 have a CPU ID (note the space between CPU and ID) value which they supply in EDX register after RESET. This is consumed by BIOS as it's (by default) the first in exec flow after reset. In such case the CPU ID value can be retrieved either via a dedicated BIOS INT call (if the BIOS supports this service, which many don't) or using a trick by issuing a CPU RESET and taking control (to catch the EDX value) before the BIOS does and then restoring the current state. That's the various CPU RESET 1-3 methods used by HWiNFO, they differ by implementation type.

phantom_pl wrote on 2020-04-15, 13:27:

Hi […]
Show full quote

Hi

Gigabyte AM/S rev. 2.20 has been tested using HWiNFO 6.05 with following CPUs:
1. AMD Am5x86DX5-133V16BHC (Kingston Turbochip 133, with L1 Cache WT locked)
2. AMD Am486DX4-100V16BGC
3. AMD Am486DX4-100NV8T
4. AMD Am486DX2-80N
5. Intel i486SX-25
6. Intel i486DX-50
7. Intel i486DX2-66 (P24D)
8. Cyrix Cx486DX2-v66GP
9. ST486DX2-66GS
10. UMC U5S-Super40

Issues found:
• Program crashes if CPU detection method 1 is used, and CPU does not support CPUID instruction. All tests have been done using CPU detection method 2
• Program crashes when trying to save report file, if BIOS flash detection is enabled. When it’s enabled, and you do not try to “check” BIOS details, and do not generate a report, it is okay then. (P.S. this board does have a flash BIOS – SST 29EE010/5v chip)
• Intel i486SX-25 is detected as i486DX-25 chip
• Not an issue actually, but it would be great, if there would be possibility, to have an option to be asked for a log file name. It would enable to include program to autoexec.bat file, and would eliminate the need of manually starting HWINFO (yes, I know, I’m lazy).

Regards

I did some updates - improved detection of L2 cache size for UMC UM8881F chipset and detection of 486SX when CPU ID can't be read. Could you please run a new test on the 486SX with this build:

As for detection difference between SX and DX i486 chips, couldn't you run some floating point math X number of times, or run some integration or series summation where the upper bound is set high enough such that you can compare the response time difference between SX and DX? Shouldn't there be an order of magnitude or more different and you can make a fairly confident guess based on the clock speed and response time if the chip is SX or DX?

I have repeated Intel i486SX-25 test.
Program does work using all CPU detection method (with this specific CPU), but still is identified as DX25.
I also pulled off the storage another old CPU – Cyrix DX 40, and tested it using revised version of HWinfo, but in this case program behaved like before – works fine using Method 2, but crashes when Method 1 is checked.
regards

phantom_pl wrote on 2020-04-16, 05:54:

I have repeated Intel i486SX-25 test. Program does work using all CPU detection method (with this specific CPU), but still is id […]
Show full quote

I have repeated Intel i486SX-25 test.
Program does work using all CPU detection method (with this specific CPU), but still is identified as DX25.
I also pulled off the storage another old CPU – Cyrix DX 40, and tested it using revised version of HWinfo, but in this case program behaved like before – works fine using Method 2, but crashes when Method 1 is checked.
regards

Thanks for the report. Interesting that Method 1 worked, yet the CPU ID obtained is crippled. Probably the BIOS was able to gain control after reset before HWiNFO..
As for the 486SX - does the machine perhaps have an FPU ? In the previous test HWiNFO reported no FPU, now it looks as if there was one.

Mumak wrote on 2020-04-16, 06:43:

As for the 486SX - does the machine perhaps have an FPU ? In the previous test HWiNFO reported no FPU, now it looks as if there was one.

Quake definitely claim there is no FPU, and refuses tu run

phantom_pl wrote on 2020-04-16, 06:59:

Mumak wrote on 2020-04-16, 06:43:

As for the 486SX - does the machine perhaps have an FPU ? In the previous test HWiNFO reported no FPU, now it looks as if there was one.

Quake definitely claim there is no FPU, and refuses tu run

Please try to run with Method 1 disabled if it will still show 486DX or SX perhaps.

Sorry, still the same - 486DX

phantom_pl wrote on 2020-04-16, 12:15:

Sorry, still the same - 486DX

Is there any "Math Co-Processor:" entry perhaps?

Found nothing

I put the same CPU to another board (FIC 486-GVT-2), and is recognizable properly using all 3 methods.
Program however hangs if trying to make report (on peripherals).
I checked another CPU - the same.
Maybe the problem is controller& I/O card, but I can check it in the next week.

You find enclosed also another report - a P Pro 200 system (just have arrived).
Battery is flat, and I can't acces it's BIOS (need special Compaq software), but it managed to generate a report.

regards

phantom_pl wrote on 2020-04-16, 13:34:

Found nothing […]
Show full quote

Found nothing

I put the same CPU to another board (FIC 486-GVT-2), and is recognizable properly using all 3 methods.
Program however hangs if trying to make report (on peripherals).
I checked another CPU - the same.
Maybe the problem is controller& I/O card, but I can check it in the next week.

You find enclosed also another report - a P Pro 200 system (just have arrived).
Battery is flat, and I can't acces it's BIOS (need special Compaq software), but it managed to generate a report.

regards

Thanks for the new results!
Since the CPU Reset method worked on the FIC board, it could also properly retrieve the CPU ID and identified it as 486SX.
Would be great if you could take a screenshot where it hangs on the Peripherals screen if you open it manually.
And I think I finally found the bug in non-FPU detection, could you please re-test the 486SX in GIGABYTE using the build posted here: Re: HWiNFO for DOS resurrected !

I'll do all that, but not until Monday (no time tomorrow, and no hardware on weekend) 🙁

Motherboard is a Daewoo AL486V-D, aka Panda 386V.
SXL2-50 running at 2x25 MHz with Cyrix FasMath CX-83D87

See comments in the photos.