Sure, a report will be great 😀 I see that others have issues here too, but with your help we can get it to next level 😀

Yeah, let's put the other DOS hardware utilities to shame! I'm pretty disappointed with ASTRA. That utility has been around for a long time and is still being developed, but it let me down. Maybe that developer will be on vogons next.

Here's the log file.

It didn't hang on ISA and other device check, didn't hang on peripherals, obviously SCSI info not available. Available IRQ's same as before. Chipset still reads SCREAMER. And Math Co-Pro shows NONE. So far, none of the other software could correctly identify this copro, but one at least measured its speed correctly at 66 MHz.

Ah yes, I just see I made a mistake in the FPU detection code.. But I guess you're heading to bed now, so let's continue tomorrow.

Yeah, all done for now.

I tried to run Norton Diagnostics version 8.1. It gave me the same out of memory error that yours does, so I booted with the MS DOS boot floppy to just load himem. Program runs, but hangs right when it opens. This must be a pretty odd system to debug.

Hello!
I use version HWINF605.
It does not work when I choose "Mainboard info" from the menu.
Main motherboard is GIGABYTE H81M-S2V
Runs with the -r option working fine.

Mumak wrote on 2020-04-18, 07:10:

Please try the latest build I posted here: Re: HWiNFO for DOS resurrected !
If it still hangs can you please take a picture so I can see where exactly it did ?

I did that, it hangs just immediately after opening the System Information tab.

appreciate the update for this tool, i had tried the old version before and was a bit surprised seeing a ~500kb requirement in the readme when in reality it was more like 600kb. now it's finally runnable without too much hassle.

just a small thing i've noticed, my batman's revenge board (430LX) was misdetected as a plato board (430NX). this goes for both DOS and windows versions.

I have completely rewritten the FPU test, so here a new test build:
[build pulled, newer available]
But meanwhile I found another bug which is affecting much newer systems and is probably causing hangs as recently reported by others. I'm still working on resolving this...

Hello Mumak,

I saw this thread, and I'd thought I'd help.

Never have I've been so excited to run HWINFO before! (being serious) I grabbed the latest version from your website (modified date April 13, 2020), which is older than the one you just posted above, but I encountered no issues, so I guess it doesn't really matter, eh?

I'm really impressed. It felt so cool to see all the specs of the system under DOS. Probs one of the coolest DOS programs I've used, but then again I don't have much DOS experience (I don't really use DOS except to play DOS games).

Anywho, as you can see, I used my Pentium MMX machine as the test candidate, running HWINFO under its DOS 6.22 install, using the XMS (Extended Memory) manager. (If you want an overview of the system, click here)

I've attached the log for the program as well if you are interested.

the_ultra_code wrote on 2020-04-20, 07:21:

Hello Mumak, […]
Show full quote

Hello Mumak,

I saw this thread, and I'd thought I'd help.

Never have I've been so excited to run HWINFO before! (being serious) I grabbed the latest version from your website (modified date April 13, 2020), which is older than the one you just posted above, but I encountered no issues, so I guess it doesn't really matter, eh?

I'm really impressed. It felt so cool to see all the specs of the system under DOS. Probs one of the coolest DOS programs I've used, but then again I don't have much DOS experience (I don't really use DOS except to play DOS games).

Anywho, as you can see, I used my Pentium MMX machine as the test candidate, running HWINFO under its DOS 6.22 install, using the XMS (Extended Memory) manager. (If you want an overview of the system, click here)

I've attached the log for the program as well if you are interested.

Thank you 😀 It's great to see that everything worked there well!

Attached is the log for HWiNFO on the SXL2-66/screamer configuration.

FPU detection is almost correct. The FPU installed is a:
Math-Co DX-2 66 MHz
US83D87-C

Do you intend to have HWiNFO show the FPU operating frequency?

Chipset still shows as SCREAMER rather than VLSI Topcat. IRQ's 10, 11, 12 still show as free. IRQ5 shows as FREE with LPT2, which I guess is a default fall-back of sorts.

All the DOS utilities I've tested so far have been able to detect my PS/2 mouse on IRQ 12. Will HWiNFO be able to do this in the future?

Peripherals Information shows Sound Card: Not Present. If detecting the make/model of the sound card is problematic, is there a less intrusive routine you can run to detect that there is a sound card present on IRQ5? I wonder if I load the sound card drive, if NWiNFO will show a sound card present...

Thanks.
Do you maybe have more information about the various ULSI FPUs? Currently I can recognize U83S87 and U83C87 only. I'm not sure about your US83D87 model, is that still the ULSI brand? How is it different from the S or C ?
FPU clock detection - I have code for this and it was working in the past. But I removed it in later versions to save memory..

Chipset recognition - this doesn't work, as you have seen the chipset doesn't respond per the VLSI documents, so I can't detect it 🙁

Yes, I will have a look at PS/2 detection, but a bit later once I can clear my large queue of other issues.

Sound card - I think that if you'd load the sound card driver, detection might work. I assume that it will do the PnP init (which is not done by your BIOS as it's not PnP-compliant). This would be interesting to know as I'm still planning to somehow add PnP init for such cases and was wondering if that would help in this case too.

Yes it is ULSI. The chip looks like this: http://www.chipdb.org/img-ulsi-387-dx2-66-mhz … 3d87-c-3754.htm

If you cannot get HWiNFO to run on 500 KB or less, I think leaving the FPU speed detection in place may be worthwhile. How much memory does it consume?

This FPU is different in that it clock doubles. Other than that, it is similar to the C variant. There is an IIT version that also clock doubles, but is limited to 2x25 MHz. The ULSI DX2-66 is rather rare, but the IIT 2x25 is a bit easier to find.

I will check hwinfo with the sound card driver loaded.

Roughly checking the FPU clock detection will occupy ~5 KB more.
So we can say that if ULSI FPU clock >= 50 MHz, it's the D variant?
FPU detection is quite limited, there are no IDs, nothing just tests to find out differences in math/flag results. So we can't expect here to always have precise identification.

Yes, I think so. I looked on chipdb.org and all the clock doubled ULSI chips (50 & 66 MHz) have the D, while none of the 33/40 MHz ULSI chips have the D.

Here's the ULSI 50 MHz: http://www.chipdb.org/img-ulsi-dx-dlc-2-50-7133.htm

I enabled the ESS sound card driver. HWiNFO finds a sound card, but the incorrect one. I've seen other DOS hardware utilities incorrect label it as a creative labs card as well. I know at least one got it right, but forget which. HWiNFO identifies the sound card as a Creative Labs Sound Blaster Pro (CT1335). I think the ESS AudioDrive 1868 is at least SB Pro compatible, so its a good start.

Report attached for the cased with the ESS drivers installed.

Yes, the Sound Card is SB-compatible, hence it's detected as such.
But I also have dedicated code to detect ESS cards including ES1868, don't know why it didn't work here. Please try this build what it will report:
[pulled, newer build available]

Here's the repot. Still shows a sound blaster.

OK, it looks like ESS made a bit of mess according to the documents I just read...
Please do a new test using the "debug" tool and post what it returns:

1i 226
2i 226
3
4i 224
5i 226
6i 226
7
8i 22C
9i 226
10i 226
11
12i 22A
13i 226
14i 226

Here's the debug.

Thanks, but I can hardly recognize the content, the image is too small 🙁