Mumak wrote on 2020-10-19, 10:06:

Q: Separate one. I was wondering why your tool is giving so little info (just name, no memory sizes or clock) on my Gainward Dra […]
Show full quote

Q: Separate one. I was wondering why your tool is giving so little info (just name, no memory sizes or clock) on my Gainward Dragon 3000 Voodoo 2 card. Is it because I'm using nonstandard 3dfxzone.it Fastvoodoo v4.6 driver or is it about my specific hw version.
--------------

Thanks for the feedback.
Yes, that issue might be due to using a non-stanadard driver. With standard drivers it should report memory size and clocks too.
If you can post a dump of the registry "HKEY_LOCAL_MACHINE\Software" key I will look into that.

Do you really need my full software library listing? You are I suppose interested only about [HKEY_LOCAL_MACHINE\Software\3dfx Interactive] content...
So here we go, regedit export attached.

Sidenote: I have done a lot back and forth testing with current win98SE install. So general state of win drivers might be affected. For example I tried to install Gainward original ver 1.0 drivers and while it didn't give any errors games just didn't work. So I uninstalled everything. Removed all voodoo .inf files from windows\inf\others dir. Even removed [HKEY_LOCAL_MACHINE\Software\3dfx Interactive] key. Then did new clean install with fastvoodoo2_4.6 drivers.
All games and 3dmarks I tested worked without a hitch.

vutt wrote on 2020-10-19, 11:43:

Do you really need my full software library listing? You are I suppose interested only about [HKEY_LOCAL_MACHINE\Software\3dfx […]
Show full quote

Mumak wrote on 2020-10-19, 10:06:

Q: Separate one. I was wondering why your tool is giving so little info (just name, no memory sizes or clock) on my Gainward Dra […]
Show full quote

Q: Separate one. I was wondering why your tool is giving so little info (just name, no memory sizes or clock) on my Gainward Dragon 3000 Voodoo 2 card. Is it because I'm using nonstandard 3dfxzone.it Fastvoodoo v4.6 driver or is it about my specific hw version.
--------------

Thanks for the feedback.
Yes, that issue might be due to using a non-stanadard driver. With standard drivers it should report memory size and clocks too.
If you can post a dump of the registry "HKEY_LOCAL_MACHINE\Software" key I will look into that.

Do you really need my full software library listing? You are I suppose interested only about [HKEY_LOCAL_MACHINE\Software\3dfx Interactive] content...
So here we go, regedit export attached.

Sidenote: I have done a lot back and forth testing with current win98SE install. So general state of win drivers might be affected. For example I tried to install Gainward original ver 1.0 drivers and while it didn't give any errors games just didn't work. So I uninstalled everything. Removed all voodoo .inf files from windows\inf\others dir. Even removed [HKEY_LOCAL_MACHINE\Software\3dfx Interactive] key. Then did new clean install with fastvoodoo2_4.6 drivers.
All games and 3dmarks I tested worked without a hitch.

Thanks for the dump. Indeed, I was interested in the "3dfx Interactive" node only, but since HWiNFO didn't report any of those values I thought it's not present with this driver set.
Now I can see that memory information is missing there, hence why HWiNFO doesn't report it. But at least the GPU clock should be reported, isn't it?
I have spent a lot of time trying to implement direct readout of those parameters from the chip, but it didn't work. The registers just didn't behave the way they were described in specifications. Also some parameters could not be retrieved on a system which is actively running (driver with active tasks) as it could cause issues. So all that I ended up was to read those registry parameters. I always strive to read information from HW directly, but that wasn't possible in this case 🙁

Mumak still thank you for your effort anyway.

It seems complicated indeed, because even contemporary devs when this hardware was more relevant weren't able to determine memory sizes. Both early 2000's Everest and 3DMark 2001SE are not able to determine memory sizes 4 + 8 MB in my case. However both of them are showing clock value.

For reference how it looks like for me in HWInfo atm.

vutt wrote on 2020-10-19, 16:22:

Mumak still thank you for your effort anyway.

It seems complicated indeed, because even contemporary devs when this hardware was more relevant weren't able to determine memory sizes. Both early 2000's Everest and 3DMark 2001SE are not able to determine memory sizes 4 + 8 MB in my case. However both of them are showing clock value.

For reference how it looks like for me in HWInfo atm.

Thanks. Looks like there is be a bug in the current HWiNFO versions preventing it from showing some data (i.e. clocks) on Voodoo2. Let me try to fix that in the next build 😉

vutt wrote on 2020-10-19, 16:22:

Mumak still thank you for your effort anyway.

It seems complicated indeed, because even contemporary devs when this hardware was more relevant weren't able to determine memory sizes. Both early 2000's Everest and 3DMark 2001SE are not able to determine memory sizes 4 + 8 MB in my case. However both of them are showing clock value.

For reference how it looks like for me in HWInfo atm.

Could you please try version 6.33-4285 Beta if it fixes that issue?

Hello Mumak,

A few months ago, I came here to ask as to why HWINFO32 wasn't showing any sort of temperature sensors that are on my Asus TUSL2-C motherboard with a Intel Pentium III-S 1.4Ghz Tualatin CPU. After showing you the log and debug files I gathered at the time, you replied that you were unable to find such sensors on the board. Even still, with the latest version, such sensors are not visible (although before I started experimenting with some settings, a sensor chip was mentioned, although with no accompanying sensor data):

However, as of late, I looked around at some contemporary software, and found that they were able to find such temperature sensors on my board - Everest Home and SpeedFan v4.5.

Both mention an Asus AS99127F sensor chip, although in the SpeedFan sensor settings, it also mentions a LM75 sensor which is responsible for measuring CPU temps separate from the motherboard temps, which are measured by the aforementioned Asus sensor. The Asus AS99127F sensor is what HWINFO32 was able to vaguely see before I experimented with some settings, and even after reversing those tweaks, the name of the sensor refuses to show itself anymore in the sensor list.

If there's some way you can figure out how to read this sensor from within HWINFO32, that'd be awesome. I've included HWINFO32 report and debug files as requested (the report file includes sensor loggings at the bottom), as well as an Everest report file for reference (it doesn't show additional information from what's shown in the above screenshot, though).

Let me know if you need anything else.

the_ultra_code wrote on 2020-10-29, 22:39:

Hello Mumak, […]
Show full quote

Hello Mumak,

A few months ago, I came here to ask as to why HWINFO32 wasn't showing any sort of temperature sensors that are on my Asus TUSL2-C motherboard with a Intel Pentium III-S 1.4Ghz Tualatin CPU. After showing you the log and debug files I gathered at the time, you replied that you were unable to find such sensors on the board. Even still, with the latest version, such sensors are not visible (although before I started experimenting with some settings, a sensor chip was mentioned, although with no accompanying sensor data):

However, as of late, I looked around at some contemporary software, and found that they were able to find such temperature sensors on my board - Everest Home and SpeedFan v4.5.

Both mention an Asus AS99127F sensor chip, although in the SpeedFan sensor settings, it also mentions a LM75 sensor which is responsible for measuring CPU temps separate from the motherboard temps, which are measured by the aforementioned Asus sensor. The Asus AS99127F sensor is what HWINFO32 was able to vaguely see before I experimented with some settings, and even after reversing those tweaks, the name of the sensor refuses to show itself anymore in the sensor list.

If there's some way you can figure out how to read this sensor from within HWINFO32, that'd be awesome. I've included HWINFO32 report and debug files as requested (the report file includes sensor loggings at the bottom), as well as an Everest report file for reference (it doesn't show additional information from what's shown in the above screenshot, though).

Let me know if you need anything else.

I have just recently fixed a bug in sensor support of some old ASUS boards. Please try the latest Beta build (v6.33-4290) and let me know if it works now.

Mumak wrote on 2020-10-29, 23:14:

I have just recently fixed a bug in sensor support of some old ASUS boards. Please try the latest Beta build (v6.33-4290) and let me know if it works now.

Nice! Thanks! Both motherboard and CPU temps are shown. The Aux sensor is a bit confused, but it's probs nothing to worry about. 😀

Thanks for the feedback, happy to see it working now. The Aux temp is most likely invalid (not connected). CPU seems also very low..
Nice GPU you have there 😉

Mumak wrote on 2020-10-29, 23:39:

Thanks for the feedback, happy to see it working now. The Aux temp is most likely invalid (not connected). CPU seems also very low..
Nice GPU you have there 😉

No problem.

I delidded my Tualatin, sanded the IHS, and am using Thermal Grizzly Kryonaut between the die and IHS, and between the IHS and Startech S370 cooler. I did this for fun and so I could free up some thermal headroom for some light CPU OCing. However, said light OCing has somehow caused... complications with the V5 5500 that was in the system, so rn using my V4 4500 until I can fix the issues with my V5 (hopefully). In the meantime, I will never do FSB OCing again with a 3dfx card in the system if I can't lock the AGP frequency.

the_ultra_code wrote on 2020-10-30, 00:01:

I delidded my Tualatin, sanded the IHS, and am using Thermal Grizzly Kryonaut between the die and IHS, and between the IHS and Startech S370 cooler. I did this for fun and so I could free up some thermal headroom for some light CPU OCing. However, said light OCing has somehow caused... complications with the V5 5500 that was in the system, so rn using my V4 4500 until I can fix the issues with my V5 (hopefully). In the meantime, I will never do FSB OCing again with a 3dfx card in the system if I can't lock the AGP frequency.

Hate to break it to ya, but it's impossible for your CPU to have less than ambient temperatures, unless you use liquid nitrogen or some type of phase cooling like a freezer would. Of course, it's not impossible for your room to be ~10C, but that would be too cold for comfort..
Just out of curiosity, is the die of the Tualatin smaller than a Coppermine? Never mind, I googled it, and as it turns out, not really.

Mumak wrote on 2020-10-25, 09:23:

vutt wrote on 2020-10-19, 16:22:

Mumak still thank you for your effort anyway.

It seems complicated indeed, because even contemporary devs when this hardware was more relevant weren't able to determine memory sizes. Both early 2000's Everest and 3DMark 2001SE are not able to determine memory sizes 4 + 8 MB in my case. However both of them are showing clock value.

For reference how it looks like for me in HWInfo atm.

Could you please try version 6.33-4285 Beta if it fixes that issue?

I run latest beta 4290. It looks like it isn't working - Voodoo 2 with 50GB VRAM 😀, still no GPU clock...

vutt wrote on 2020-11-01, 19:45:

I run latest beta 4290. It looks like it isn't working - Voodoo 2 with 50GB VRAM 😀, still no GPU clock...
4290.jpg

Thanks. Found another bug, sorry about that. Shall be fixed in the next build.

Mumak wrote on 2020-11-01, 22:04:

vutt wrote on 2020-11-01, 19:45:

I run latest beta 4290. It looks like it isn't working - Voodoo 2 with 50GB VRAM 😀, still no GPU clock...
4290.jpg

Thanks. Found another bug, sorry about that. Shall be fixed in the next build.

Tested Voodoo 2 with 635_4305. Voodoo 2 GPU clock is now showing up correctly - 93MHz

vutt wrote on 2020-11-14, 18:41:

Mumak wrote on 2020-11-01, 22:04:

vutt wrote on 2020-11-01, 19:45:

I run latest beta 4290. It looks like it isn't working - Voodoo 2 with 50GB VRAM 😀, still no GPU clock...
4290.jpg

Thanks. Found another bug, sorry about that. Shall be fixed in the next build.

Tested Voodoo 2 with 635_4305. Voodoo 2 GPU clock is now showing up correctly - 93MHz

Perfect, thanks for the feedback.

I have tryed the last hwinfo version for DOS on an Olivetti machine. It detects the BIOS as unknown manufacturer while Checkit 3.0 detects it correctly as Olivetti. It also detects my Trident 8900C VGA card as a Trident 8900A/B.

1ST1 wrote on 2020-11-22, 20:53:

I have tryed the last hwinfo version for DOS on an Olivetti machine. It detects the BIOS as unknown manufacturer while Checkit 3.0 detects it correctly as Olivetti. It also detects my Trident 8900C VGA card as a Trident 8900A/B.

Can you please provide the HWiNFO Report + Debug File for analysis? Just run as HWINFO -r -d
It would be also useful if you could provide the main BIOS dump.

HWiNFO (and just about any other tool) doesn't read SPD data from the SMSC SLC90E66, a rare southbridge that mostly mimics the PIIX4 (apparently with Intel's blessing). It has the same function layout as the PIIX4, and according to the datasheet (p. 149-154) and the Linux kernel (l. 785), the same SMBus controller located in the power management function, which has a PCI ID of 1055:9463.

RichardG867 wrote on 2020-12-11, 20:09:

HWiNFO (and just about any other tool) doesn't read SPD data from the SMSC SLC90E66, a rare southbridge that mostly mimics the PIIX4 (apparently with Intel's blessing). It has the same function layout as the PIIX4, and according to the datasheet (p. 149-154) and the Linux kernel (l. 785), the same SMBus controller located in the power management function, which has a PCI ID of 1055:9463.

Thanks for the feedback and info! This one should be easy, please try this build and let me know if it works: www.hwinfo.com/beta/hwi32_641_4331.zip

Mumak wrote on 2020-12-11, 20:53:

Thanks for the feedback and info! This one should be easy, please try this build and let me know if it works: www.hwinfo.com/beta/hwi32_641_4331.zip

Works perfectly, I get all the SPD data now. Thanks.