Nexxen wrote on 2021-01-06, 20:47:

Hope it's useful.

Thanks. An interesting system 😀

STB Nitro DVD 4MB AGP (Chromatic Mpact 2).

Takedasun wrote on 2021-01-09, 17:15:

STB Nitro DVD 4MB AGP (Chromatic Mpact 2).

HWiNFO32.png

mpact2.png

Thanks, I'll try to fix the memory size in the next Beta build.

I have a 486 DX4 100 that shows up as 50 MHz in HWINFO 6.12:

During bootup the Bios screen indicates the correct 100 MHz.

mbertheau wrote on 2021-01-10, 00:28:

I have a 486 DX4 100 that shows up as 50 MHz in HWINFO 6.12: […]
Show full quote

I have a 486 DX4 100 that shows up as 50 MHz in HWINFO 6.12:

IMG_20210109_195501.jpg

IMG_20210109_195514.jpg

During bootup the Bios screen indicates the correct 100 MHz.

Can you please attach the HWiNFO Debug File? This can be created by running with the -d argument.

mbertheau wrote on 2021-01-10, 00:28:

I have a 486 DX4 100 that shows up as 50 MHz in HWINFO 6.12:

Ok, disregard that. I had the computer out of the case on the table and the turbo was off 😀 It's showing 100 MHz now with the turbo on. And Warcraft 2 runs nicely fast 😀

Mumak wrote on 2021-01-10, 07:53:

Can you please attach the HWiNFO Debug File? This can be created by running with the -d argument.

I have a PcChips M326 V5.2 motherboard with an Am386DX-40 soldered in, and I added an IIT 4C87DLC-40 FPU.

The motherboard is detected as M601/602 which is not correct (that one is a 486 board with 3 VLB slots), and the FPU is detected as Intel 80387DX running at 73.6 MHz. Weird. (NSSI detects it correctly)

Here's the debug:

1HWiNFO v6.1.2 
2Flushing disk caches ...
3
4Reading Data ...
5
6DetectCPU - 386
7FPUtest=3
8Check Cx
9Get freq
10FreqCPU: 1292-26
11
12Cache   1K:    32.0 ->     32.0
13Cache   2K:    62.5 ->     62.5 = 1.95x
14Cache   4K:   123.5 ->    123.5 = 1.98x
15Cache   8K:   245.5 ->    245.5 = 1.99x
16Cache  16K:   489.3 ->    489.3 = 1.99x
17Cache  32K:   977.0 ->    977.0 = 2.00x
18Cache  64K:  1956.0 ->   1956.0 = 2.00x
19Cache 128K:  3908.0 ->   3908.0 = 2.00x
20Cache 256K: 20687.0 ->  20687.0 = 5.29x *L2*
21Cache 512K: 41366.0 ->  41366.0 = 2.00x
22Cache 640K: 51705.0 ->  51705.0 = 1.25x
23Check CT
24Check FPU: int
25FreqFPU: 3632
26
27DetectCPU - 386
28FPUtest=3
29Resetting CPU [Method 3]
30
31Resetting CPU [Method 1]
32CPU ID1=308
33
34Check Cx
35Get freq
36FreqCPU: 1291-25
37
38Cache   1K:    32.4 ->     32.4
39Cache   2K:    62.5 ->     62.5 = 1.93x
40Cache   4K:   123.5 ->    123.5 = 1.98x
41Cache   8K:   245.4 ->    245.4 = 1.99x
42Cache  16K:   489.1 ->    489.1 = 1.99x
43Cache  32K:   977.0 ->    977.0 = 2.00x
44Cache  64K:  1956.0 ->   1956.0 = 2.00x
45Cache 128K:  3909.0 ->   3909.0 = 2.00x
46Cache 256K: 20689.0 ->  20689.0 = 5.29x *L2*
47Cache 512K: 41369.0 ->  41369.0 = 2.00x
48Cache 640K: 51684.0 ->  51684.0 = 1.25x
49Check CT
50Check FPU: int
51FreqFPU: 3632
52
53AMI ID = 40-0100-001437-00101111-080893-4386
54Checking VLSI 330
55Checking VLSI 331
56
57AMI STR = AMIBIOS (C)1993 American Megatrends Inc.,                                     
58
59Release 10/01/93.                                                             
60

61                                                                              
62
63
64Searching for BIOS extensions...
65
66

Here's another one. In this case, the motherboard is an Octek Jaguar V rev 1.4, also with a DX-40 soldered in. This time the IIT 4C87DLC-40 (which is not the same as the one in the motherboard I posted above) is correctly identified as IIT, but incorrectly as 3C87 (though they might be the same chip).

Debug:

1HWiNFO v6.1.2 
2Flushing disk caches ...
3
4Reading Data ...
5
6DetectCPU - 386
7FPUtest=3
8Check Cx
9Get freq
10FreqCPU: 1295-26
11
12Cache   1K:    32.4 ->     32.4
13Cache   2K:    63.0 ->     63.0 = 1.95x
14Cache   4K:   124.4 ->    124.4 = 1.97x
15Cache   8K:   248.0 ->    248.0 = 1.99x
16Cache  16K:  1672.9 ->   1672.9 = 6.75x *L1*
17Cache  32K:  3350.0 ->   3350.0 = 2.00x
18Cache  64K:  6700.0 ->   6700.0 = 2.00x
19Cache 128K: 13406.0 ->  13406.0 = 2.00x
20Cache 256K: 26808.0 ->  26808.0 = 2.00x
21Cache 512K: 53619.0 ->  53619.0 = 2.00x
22Cache 640K:  1489.0 ->  67025.0 = 1.25x
23Check CT
24Check FPU: IIT
25FreqFPU: 3640
26
27DetectCPU - 386
28FPUtest=3
29Resetting CPU [Method 3]
30
31Resetting CPU [Method 1]
32CPU ID1=308
33
34Check Cx
35Get freq
36FreqCPU: 1294-26
37
38Cache   1K:    32.4 ->     32.4
39Cache   2K:    63.0 ->     63.0 = 1.95x
40Cache   4K:   124.4 ->    124.4 = 1.97x
41Cache   8K:   247.8 ->    247.8 = 1.99x
42Cache  16K:  1673.9 ->   1673.9 = 6.76x *L1*
43Cache  32K:  3349.0 ->   3349.0 = 2.00x
44Cache  64K:  6701.0 ->   6701.0 = 2.00x
45Cache 128K: 13404.0 ->  13404.0 = 2.00x
46Cache 256K: 26809.0 ->  26809.0 = 2.00x
47Cache 512K: 53619.0 ->  53619.0 = 2.00x
48Cache 640K:  1490.0 ->  67026.0 = 1.25x
49Check CT
50Check FPU: IIT
51FreqFPU: 3640
52
53AMI ID = 31-0100-426069-00101111-121291-MXIC
54Checking VLSI 330
55Checking VLSI 331
56
57AMI STR = AMIBIOS (C)1991 American Megatrends Inc.,                                     
58
59MX_DIR_001                                                                    
60

61                                                                              
62
63
64Searching for BIOS extensions...
65
66

Thanks for the reports, those are interesting systems!
I will adjust the mainboard names so it will be correctly reported.
But the FPU detection is quite strange and I have no clue why the IIT check works on one machine, but doesn't on another one with the same FPU model.
Can you try to open the main screen multiple times to see if the reporting is consistent on each run?
Is there perhaps documentation for that IIT available somewhere?

Mumak wrote on 2021-01-27, 19:40:

Thanks for the reports, those are interesting systems! I will adjust the mainboard names so it will be correctly reported. But t […]
Show full quote

Thanks for the reports, those are interesting systems!
I will adjust the mainboard names so it will be correctly reported.
But the FPU detection is quite strange and I have no clue why the IIT check works on one machine, but doesn't on another one with the same FPU model.
Can you try to open the main screen multiple times to see if the reporting is consistent on each run?
Is there perhaps documentation for that IIT available somewhere?

If you check THIS POST that I made some minutes ago, you'll see that even if the IIT FPUs are the same externally, internally there are differences. I will swap them around and check how HWInfo behaves in that case. If the "IIT" correct report follows an FPU or remains with the same motherboard regardless of which one is plugged in. I'll let you know later.

Ok, as I had the Jaguar V on the bench I went and removed the fpu and swapped it with the one on the M326, and HWInfo reports it as an Intel 80387DX at 73.6 MHz, just like the M326. So both FPUs are clearly different (even though they look identical) and they might report a different string to software, I don't know.

I tried NSSI and it's also seeing it as and Intel 387 (instead of the IIT), so my quote in the previous posts was wrong, but the frequency differs from HWInfo, it sees it as 53 mhz.

Well, that's interesting. The FPU doesn't report and string, no identification data. It can be only tested using various unique results to detect at least the vendor or type. Various vendors or families have peculiarities that can be tested.
So there's a check method for an IIT FPU (based on denormal result) and the fact that this one reports as 387DX means this check if failing there.
So my conclusion is that it's either some very early IIT FPU or rather a clone attempt of the Intel 387DX or a faked IIT FPU.

Now that I look at more details especially FPU clock detection based on execution time, it's clearly not a 387DX as that one has much longer execution times for certain instructions.
I'd rather say that the brownish one is an early IIT part that didn't yet support all later quirks.

Mumak wrote on 2021-01-27, 20:55:

Now that I look at more details especially FPU clock detection based on execution time, it's clearly not a 387DX as that one has much longer execution times for certain instructions.
I'd rather say that the brownish one is an early IIT part that didn't yet support all later quirks.

Yup, the brownish one is ~15 weeks older, which is not that much anywyas. I'm thinking maybe they are different batches of FPUs for different factories (hence the color difference) with different cores. Something interesting I found also, is that there are some IIT 3C87 with the same code as my 4C87DLC, 1002FA2F5HC0C, but they were made on the same date as my brownish one, and are brownish!. If only we could decode that string...

What a mess 😁

PCInfo Version 4.04 detects the black one (newer) as IIT 3C87 / Intel RapidCAD while it detects the brownish one (older) as IIT 3C87 / IIT 3C87sx.

Or maybe the brownish one is somehow defect or unstable and it fails (besides the IEEE test) the generic IIT check. Maybe sometimes, maybe permanently...

Mumak wrote on 2021-01-27, 21:26:

Or maybe the brownish one is somehow defect or unstable and it fails (besides the IEEE test) the generic IIT check. Maybe sometimes, maybe permanently...

I don't want to say that's impossible, because obviously it isn't, but pretty improbable. They both work perfectly fine with all software I throw at them, they perform identical even to the decimals in benchmarks that take care of the fpu. They just seem to behave different in some specific area. BTW the one that is detected as "Intel" is the black one. The brown one is detected as IIT.

As I have recently been converting all my daily use machines from Windows to Linux, I was left perplexed by the lack of a "Device Manager", Astra, Everest, or hwinfo type of utility in Ubuntu. While there are a few add-on packages, they are very lacking in detail. I was wondering if there has been any thought in creating a hwinfo version for Linux?

feipoa wrote on 2021-02-16, 00:28:

As I have recently been converting all my daily use machines from Windows to Linux, I was left perplexed by the lack of a "Device Manager", Astra, Everest, or hwinfo type of utility in Ubuntu. While there are a few add-on packages, they are very lacking in detail. I was wondering if there has been any thought in creating a hwinfo version for Linux?

A thought there was, yes.. but no time and resources to dedicate to such a huge effort...

HWiNFO for DOS version 6.1.3 has just been released: Re: HWiNFO for DOS resurrected !

I want to submit a bug 😀
Nothing serious really, just that POPAD bug is not always detected on 386DX, and STOS bug is never detected. NSSI doesn't detect STOS bug either but I wrote my own code to test it and I can trigger it.