I used version Apr-21-2020.
Fatal Error (Cannot continue) after Math Co-Processor test.

CandyMan wrote on 2020-04-22, 14:37:

I used version Apr-21-2020.
Fatal Error (Cannot continue) after Math Co-Processor test.

Which system is that, can you please post a screenshot of the error so I can exactly see what appears on the screen?

Just to note that HWI build 21.4. 10:31 started to work bad on my i7, when getting Motherboard Info just empty window displays and system freeze. Even more strange I heard my HDD spinning down and after reboot I got CMOS checksum error. So you definitely play bad with some I/O registers resulting CMOS corruption! I hold backup of build 16.4. 16:32 that works well on my i7 and 386SX too.

Maybe I would suggest to get CPUID soon as possible and then decide to not run obscure legacy HW detection routines on modern HW that even has not ISA bus (just internal LPC, uumm well, there are industrial MBs with ISA where someone could push a non PnP ISA card and would want it to be detected...).

RayeR wrote on 2020-04-22, 23:38:

Just to note that HWI build 21.4. 10:31 started to work bad on my i7, when getting Motherboard Info just empty window displays and system freeze. Even more strange I heard my HDD spinning down and after reboot I got CMOS checksum error. So you definitely play bad with some I/O registers resulting CMOS corruption! I hold backup of build 16.4. 16:32 that works well on my i7 and 386SX too.

Maybe I would suggest to get CPUID soon as possible and then decide to not run obscure legacy HW detection routines on modern HW that even has not ISA bus (just internal LPC, uumm well, there are industrial MBs with ISA where someone could push a non PnP ISA card and would want it to be detected...).

That's how it works, legacy tests are skipped for modern CPUs, so I'm really surprised that something like that happened. But anything can happen in the DOS world, I have seen so many surprises.. 😁
Was the Mainboard info screen totally, not even the Main Processor line shown?
Can you please try the build posted here: Re: HWiNFO support of vintage hardware

RayeR wrote on 2020-04-22, 23:38:

Just to note that HWI build 21.4. 10:31 started to work bad on my i7, when getting Motherboard Info just empty window displays and system freeze. Even more strange I heard my HDD spinning down and after reboot I got CMOS checksum error. So you definitely play bad with some I/O registers resulting CMOS corruption! I hold backup of build 16.4. 16:32 that works well on my i7 and 386SX too.

Maybe I would suggest to get CPUID soon as possible and then decide to not run obscure legacy HW detection routines on modern HW that even has not ISA bus (just internal LPC, uumm well, there are industrial MBs with ISA where someone could push a non PnP ISA card and would want it to be detected...).

Why are you running HWiNFO for DOS on an i7? What purpose does this serve?

Mumak wrote on 2020-04-23, 06:17:

Was the Mainboard info screen totally, not even the Main Processor line shown?

No, just empty window frame.

I tested new build 22.4. 10:04, it runs but still has some problems that rsulted to crash.
1) it misdetected my SuperIO IT8728F as LPC47B37x.
2) when I did steps: display DMA info, IRQ info, Peripheral Info I got crash but not always. When I start from top (MB info) to bottom (DMA info) I didn't get crash. CMOS was not corrupted.

>Cyrix200+
Just for the same reason like Cyrix and other users, they runs it on theirs HW that can be very different. And HWI should be universal tool as possible. Eg. Astra has not problem runniong on new and old HW so why not?

Mumak wrote on 2020-04-22, 16:48:

CandyMan wrote on 2020-04-22, 14:37:

I used version Apr-21-2020.
Fatal Error (Cannot continue) after Math Co-Processor test.

Which system is that, can you please post a screenshot of the error so I can exactly see what appears on the screen?

System M$DOS 7.1. I can't publish the screenshot because the system freeze and it can't be done.
I found out that if I installed some TSR before run HWINFO, it would pass all the tests without any problems.
It looks like it depends on the address/segment into which the program was loaded.
Only the first two lines are visible on the screen.

1  ║ Main Processor:           Intel Core i3-4170, 3691.5 MHz                 ║
2  ║ Math Co-Processor:        Internal                                       ║
3  ║ Bus Type:   

CandyMan wrote on 2020-04-23, 15:38:

System M$DOS 7.1. I can't publish the screenshot because the system freeze and it can't be done. I found out that if I installe […]
Show full quote

Mumak wrote on 2020-04-22, 16:48:

CandyMan wrote on 2020-04-22, 14:37:

I used version Apr-21-2020.
Fatal Error (Cannot continue) after Math Co-Processor test.

Which system is that, can you please post a screenshot of the error so I can exactly see what appears on the screen?

System M$DOS 7.1. I can't publish the screenshot because the system freeze and it can't be done.
I found out that if I installed some TSR before run HWINFO, it would pass all the tests without any problems.
It looks like it depends on the address/segment into which the program was loaded.
Only the first two lines are visible on the screen.

Copy code to clipboard

1  ║ Main Processor:           Intel Core i3-4170, 3691.5 MHz                 ║
2  ║ Math Co-Processor:        Internal                                       ║
3  ║ Bus Type:   

Can you please try the build posted here: Re: HWiNFO support of vintage hardware

Can you please try the build posted here: Re: HWiNFO support of vintage hardware

This version works fine.

Released version 6.1.0
Changes from v6.0.5:

• Rewritten and optimized ~90% of code for lower memory usage.
• Fixed a possible crash when running without XMS manager.
• Added enumeration of PnP cards also when BIOS isn't PnP-capable.
• Fixed detection of systems without FPU.
• Added detection of FPU clock for discrete FPUs.
• Improved support and reporting of stepping for Cyrix CPUs.
• Updated detection of Adaptec AHA-154x controllers.
• Enhanced detection of ESS sound cards.
• Updated detection of various SIO chips.
• Added detection of VLSI VL82C330 and VL82C331 chipsets.
• Improved IRQ/DMA list, fixed reporting of PCI allocated resources.
• Improved detection of TI486SXL/SXL2 CPUs.
• Improved support of modern systems.

I unpacked the executable with cup386 and upx-ed with the lzma option. program size decreased by about 36k.

Yes, lzma has better compression but is slower on old machines.

as long as you realise, compressed executable needs more memory than uncompressed. you need uncompressed size + compressed size to fit in memory. few packers are smart enough to to how much of the compressed data to lay over the end of the unpacked original size, reducing the amount of ram at runtime to unpack.

Mumak wrote on 2020-04-27, 12:57:

Released version 6.1.0

Nice, it's no longer freezing on my Abit VH6T, shows up with "AGP 0x" though, which seems a bit weird.

However, I've found another bug. Two of my memory modules are displayed as a garbled string.
I have three SDRAM 512MB modules in there. They all use the same memory chips, but are from different manufacturers.

This bug is also present on HWINFO32.

schmatzler wrote on 2020-04-27, 20:32:

Nice, it's no longer freezing on my Abit VH6T, shows up with "AGP 0x" though, which seems a bit weird. […]
Show full quote

Mumak wrote on 2020-04-27, 12:57:

Released version 6.1.0

Nice, it's no longer freezing on my Abit VH6T, shows up with "AGP 0x" though, which seems a bit weird.

IMG_20200427_221319.jpg

However, I've found another bug. Two of my memory modules are displayed as a garbled string.
I have three SDRAM 512MB modules in there. They all use the same memory chips, but are from different manufacturers.

IMG_20200427_221418.jpg

This bug is also present on HWINFO32.
SnapShot.jpg

Thanks. Those memory modules look like if they would contain some garbage in the SPD. Can you please attach the Debug File from HWiNFO32?

The SPD EEPROM is not write protected so it might be corrupted by some other software that accidentally write something in. Or some chinese manufacturers sometimes fill SPD with creative data 😀 also the SPD data structure has a checksum that can be calculated if OK. This would need to take full EEPROM dump (128-256B).

Mumak wrote on 2020-04-27, 21:04:

Thanks. Those memory modules look like if they would contain some garbage in the SPD. Can you please attach the Debug File from HWiNFO32?

Here it is.

I just removed the RAM from the motherboard and turns out, it's actually meant to be put into an Apple G4 machine.
I didn't even notice it was Apple memory when I put that in, but that might explain why it's behaving so weird.

(Runs very well at 151MHz FSB though. HYB39S2568000 are good chips.)

Apple is a specific HW world, maybe they use some different (non-JEDEC) SPD data structure?
There seems to be readable manuf. string in all modules but at different offset:
63h: HYB39S256800D
63h: MT48LC32M8A2T
41h: INFINEOVHYS64V6

EDIT: No, Apple memory modules should conform JEDEC standard...
The electrical design of the SDRAM DIMM is defined by the JEDEC specification
JESD21-C, MODULES4_20_4, Release 11b. To find this specification on the World
Wide Web, refer to “RAM Expansion Modules” (page 70).
The Serial Presence Detect (SPD) EEPROM specified in the JEDEC standard is
required and must be set to properly define the DIMM configuration. The EEPROM
is powered on 3.3 V. Details about the required values for each byte on the SPD
EEPROM can be found on pages 68–70 of the JEDEC specification.
Important
For a DIMM to be recognized by the startup software, the
SPD feature must be programmed properly to indicate the
timing modes supported by the DIMM.

Those memory modules are really odd. The SPD layout isn't per JEDEC specification, I haven't seen such case yet.
Could be indeed some Apple special 'feature'. I'm wondering that the BIOS does properly detect and configure them.

I didn't compared if the timing fields differ too but maybe BIOS has some safe default or can override timing by user setting. If I remember well my Abit BX133 Raid could run a DIMM with corrupted SPD, just printed some warning at boot...