Mabye the heads are dirty on the floppy drive?

DosFreak wrote on 2020-03-22, 01:54:

Mabye the heads are dirty on the floppy drive?

Maybe, but the other 486 with a really dirty floppy drive didn't even try to load HWINFO.exe.

EvieSigma wrote on 2020-03-22, 01:47:

I ran into trouble trying out the version you have in the first post of this thread on my Gateway 486, trying to run it fails with a "Program too big to fit in memory" error. Which doesn't make sense because that 486 has 16MB of RAM and the same disk works on a 386DX with 8MB of RAM.

16mb ram, aint dos memory.

BloodyCactus wrote on 2020-03-22, 02:09:

EvieSigma wrote on 2020-03-22, 01:47:

I ran into trouble trying out the version you have in the first post of this thread on my Gateway 486, trying to run it fails with a "Program too big to fit in memory" error. Which doesn't make sense because that 486 has 16MB of RAM and the same disk works on a 386DX with 8MB of RAM.

16mb ram, aint dos memory.

I...don't know what this means. Are you saying I don't have enough conventional memory free to run the program?

EvieSigma wrote on 2020-03-22, 01:47:

I ran into trouble trying out the version you have in the first post of this thread on my Gateway 486, trying to run it fails wi […]
Show full quote

I ran into trouble trying out the version you have in the first post of this thread on my Gateway 486, trying to run it fails with a "Program too big to fit in memory" error. Which doesn't make sense because that 486 has 16MB of RAM and the same disk works on a 386DX with 8MB of RAM.

DOS programs need sufficient conventional memory. Please type „mem /c“ and show us its output. You probably need more free conventional memory.

EvieSigma wrote on 2020-03-22, 02:12:

BloodyCactus wrote on 2020-03-22, 02:09:

EvieSigma wrote on 2020-03-22, 01:47:

I ran into trouble trying out the version you have in the first post of this thread on my Gateway 486, trying to run it fails with a "Program too big to fit in memory" error. Which doesn't make sense because that 486 has 16MB of RAM and the same disk works on a 386DX with 8MB of RAM.

16mb ram, aint dos memory.

I...don't know what this means. Are you saying I don't have enough conventional memory free to run the program?

Yes, you need to free more conventional memory.

If you have enough free mem, as DosFreak point out, it could be corrupted file, i had this problems multiple times with different programs. Maybe this is default Dos error when some exe header is broken or not available, when i reimported files it always fixed this problem.

I just uploaded v6.0.3 to the initial post of this thread. Check there for list of changes.

Mumak wrote on 2020-03-22, 08:42:

EvieSigma wrote on 2020-03-22, 02:12:

BloodyCactus wrote on 2020-03-22, 02:09:

16mb ram, aint dos memory.

I...don't know what this means. Are you saying I don't have enough conventional memory free to run the program?

Yes, you need to free more conventional memory.

HWINFO requires something like 550K, correct? I only have 484K free, that explains why it won't run.

Mumak wrote on 2020-03-21, 18:51:

JazeFox wrote on 2020-03-21, 18:22:

Yes, the Cx ID for this CPU is 1F36h […]
Show full quote

Mumak wrote on 2020-03-21, 17:34:

Do you maybe know the values of DIR0 and DIR1 for this CPU? I'm not sure if it's possible to tell the ST from Cx..

Yes, the Cx ID for this CPU is 1F36h

Can you please try to manually select the Peripherals screen and take a picture when it crashes?

I can not upload files now, anyway...

Selecting the Peripherals screen manually works well. It only hangs there if -r command line argument is used.

I checked that the log file is written (despite the system hang), but it stops after this line is printed:
"Floppy Drive(s): 1.44 MB 3 1/2"

Thanks. That DIR0/1 value seems to be standard Cyrix. I don't know of any way how else to tell the ST from Cx, might not be possible at all 🙁
You can send the report file to me via e-mail too, it's shown in the program too.

Sorry for the delay. Here is the LOG:

EvieSigma wrote on 2020-03-23, 15:36:

HWINFO requires something like 550K, correct? I only have 484K free, that explains why it won't run.

There is simple solution edit msdos.sys add here Bootmenu=1 and reboot, select Command line only (it will bypass of loading of driver which im otherwise fill conventional mem).. after that navigate and run Hwinfo.

JazeFox wrote on 2020-03-24, 09:29:

Mumak wrote on 2020-03-21, 18:51:

JazeFox wrote on 2020-03-21, 18:22:

Yes, the Cx ID for this CPU is 1F36h […]
Show full quote

Yes, the Cx ID for this CPU is 1F36h

I can not upload files now, anyway...

Selecting the Peripherals screen manually works well. It only hangs there if -r command line argument is used.

I checked that the log file is written (despite the system hang), but it stops after this line is printed:
"Floppy Drive(s): 1.44 MB 3 1/2"

Thanks. That DIR0/1 value seems to be standard Cyrix. I don't know of any way how else to tell the ST from Cx, might not be possible at all 🙁
You can send the report file to me via e-mail too, it's shown in the program too.

Sorry for the delay. Here is the LOG:

Thank you! I think I figured out a way how to properly identify the ST486. I'm checking how to fix the divide error during report creation and soon will provide a new build for testing.
I can also see that the L1 cache shown is 4KB. Is it always shown as such or perhaps sometimes 8KB too ?
A question - is the CPU called ST 486DX100 or ST 486DX4-100 ?

ruthan wrote on 2020-03-24, 10:01:

EvieSigma wrote on 2020-03-23, 15:36:

HWINFO requires something like 550K, correct? I only have 484K free, that explains why it won't run.

There is simple solution edit msdos.sys add here Bootmenu=1 reboot, select Command line only (it will bypass of loading of driver which im otherwise fill conventional mem).. after that navigate and run Hwinfo.

I'm posting here a special build:

This should show the CPU as ST 486DX4.

Regarding the crash during automatic report file, I couldn't figure out what is causing this yet. Could you please go in the menu to Setup and clear the "Check PCMCIA Feature" option to see if this will solve the problem?

Additionally this special build will show a new line called "[Cache Debug]" on the mainboard screen. This information is to help me figure out how to better tune the cache detection. So it would be very helpful if you could do about 3 runs and each time save this screen content for me. If would be great if anyone else with systems showing wrong cache size could do this test for me.

Tested the special 6.0.3 version. Thanks.

Now the CPU report is:

Main Processor: Siemens-Thomson ST486DX4, 100.0 MHz
Math Co-Processor: Cyrix FasMath 83D87 New

The text printed in the CPU itself is: 486DX4-100
(below, the code is ST486DX4V10HS). It has windows logo.

About the cache:

I ran HWiNFO 5 times, all of them showed 4K cache.
The debug lines:

[Cache Debug]: 12.8 25.0 49.3 118.8 1272.8
[Cache Debug]: 12.8 25.0 49.3 118.8 1272.6
[Cache Debug]: 12.8 25.0 49.3 118.6 1272.4
[Cache Debug]: 12.8 25.0 49.3 118.6 1272.8
[Cache Debug]: 12.8 25.0 49.3 118.8 1272.7

I remember when I ran first 6.0.2 version, sometimes I saw 8K, but I saw 4K much more often.

About crash on Peripherals info:

I tried to do more detailed and intensive testing. Facts seen:

Something the program do in the Peripheral detection kill disk access (read and write). Tests done:

- In normal execution, I can go to any of the info windows, menus, change and save config, no problem at all. BUT, if I enter peripherals window, although computer does not hang, and I can navigate through windows, menus, other infos... IF disk access (R/W) is done, boom. Not ready drive C (after some minutes waiting with apparent hanging). Disk access example: save HWiNFO configuration. Or program exit, and then doing a simple "dir", or pressing F2 to save log on any window, etc. Power-cycle is required to go back to normal operation.

To eliminate some variables from the equation, I went to BIOS and disabled all peripherals I could (maintaining only primary IDE): COM ports, Parallel, floppy controller, etc...

I also disabled everything I could in HWinFO configuration (like the PCMCIA you suggested, but I disabled everything else).

No change. Same behaviour.

Suggestion: To help with de debugging, would it be possible to compile a special debug version that do some disk I/O after each interaction with the system registers you use for the detection of every piece of hardware (in the peripherals section only) to help to find where is exactly the problem?

JazeFox wrote on 2020-03-24, 12:17:

Tested the special 6.0.3 version. Thanks. […]
Show full quote

Tested the special 6.0.3 version. Thanks.

Now the CPU report is:

Main Processor: Siemens-Thomson ST486DX4, 100.0 MHz
Math Co-Processor: Cyrix FasMath 83D87 New

The text printed in the CPU itself is: 486DX4-100
(below, the code is ST486DX4V10HS). It has windows logo.

About the cache:

I ran HWiNFO 5 times, all of them showed 4K cache.
The debug lines:

[Cache Debug]: 12.8 25.0 49.3 118.8 1272.8
[Cache Debug]: 12.8 25.0 49.3 118.8 1272.6
[Cache Debug]: 12.8 25.0 49.3 118.6 1272.4
[Cache Debug]: 12.8 25.0 49.3 118.6 1272.8
[Cache Debug]: 12.8 25.0 49.3 118.8 1272.7

I remember when I ran first 6.0.2 version, sometimes I saw 8K, but I saw 4K much more often.

About crash on Peripherals info:

I tried to do more detailed and intensive testing. Facts seen:

Something the program do in the Peripheral detection kill disk access (read and write). Tests done:

- In normal execution, I can go to any of the info windows, menus, change and save config, no problem at all. BUT, if I enter peripherals window, although computer does not hang, and I can navigate through windows, menus, other infos... IF disk access (R/W) is done, boom. Not ready drive C (after some minutes waiting with apparent hanging). Disk access example: save HWiNFO configuration. Or program exit, and then doing a simple "dir", or pressing F2 to save log on any window, etc. Power-cycle is required to go back to normal operation.

To eliminate some variables from the equation, I went to BIOS and disabled all peripherals I could (maintaining only primary IDE): COM ports, Parallel, floppy controller, etc...

I also disabled everything I could in HWinFO configuration (like the PCMCIA you suggested, but I disabled everything else).

No change. Same behaviour.

Suggestion: To help with de debugging, would it be possible to compile a special debug version that do some disk I/O after each interaction with the system registers you use for the detection of every piece of hardware (in the peripherals section only) to help to find where is exactly the problem?

Thank you for your detailed report and testing!
Here a new build for test:

I made the following changes in the build above:
- Changed CPU vendor name to SGS-THOMSON
- Fixed not to report FPU in this case (it's built-in)
- Fixed reporting of cache size (hopefully)
With this build please try to disable the "Check Keyboard Controller Manufacturer" option. I found a suspicious case and changed behavior of this option to also disable checking of SIO chip. I'm curious if disabling this option now will fix the problem with disk access. If this won't help, I'll continue with other tests and your proposed method.

@Mumak

Good job, everything is ok now.

Cache size is OK all the time (tried 8 times). CPU and FPU correct too.

About SIO chip checks, you got it in the first try! It is working now, disabling the keyb controller option. No more disk access problems.

I remember some time ago when i was investigating about adding a ps/2 mouse port (read in this forum) to a 486 system i saw that this board has not a dedicated keyboard controller chip (so it should be embedded in the SuperIO chip or the UMC chipset), and did not further investigation...

JazeFox wrote on 2020-03-24, 22:21:

@Mumak […]
Show full quote

@Mumak

Good job, everything is ok now.

Cache size is OK all the time (tried 8 times). CPU and FPU correct too.

About SIO chip checks, you got it in the first try! It is working now, disabling the keyb controller option. No more disk access problems.

I remember some time ago when i was investigating about adding a ps/2 mouse port (read in this forum) to a 486 system i saw that this board has not a dedicated keyboard controller chip (so it should be embedded in the SuperIO chip or the UMC chipset), and did not further investigation...

Thanks for the feedback, I'm glad that all is well now.
The test for SIO chip does several checks for various types of SIO chips and I think one of them is causing the problem in your system. In the next build I will add automatic skipping of the entire SIO check for this UMC chipset. It would be possible to narrow this down to the particular check and fix more precisely, but that would require running several tests, which would be quite tiresome.

ruthan wrote on 2020-03-24, 10:01:

EvieSigma wrote on 2020-03-23, 15:36:

HWINFO requires something like 550K, correct? I only have 484K free, that explains why it won't run.

There is simple solution edit msdos.sys add here Bootmenu=1 and reboot, select Command line only (it will bypass of loading of driver which im otherwise fill conventional mem).. after that navigate and run Hwinfo.

I tried that but uh...something is wrong here.

EvieSigma wrote on 2020-03-25, 02:01:

I tried that but uh...something is wrong here. […]
Show full quote

ruthan wrote on 2020-03-24, 10:01:

EvieSigma wrote on 2020-03-23, 15:36:

HWINFO requires something like 550K, correct? I only have 484K free, that explains why it won't run.

There is simple solution edit msdos.sys add here Bootmenu=1 and reboot, select Command line only (it will bypass of loading of driver which im otherwise fill conventional mem).. after that navigate and run Hwinfo.

I tried that but uh...something is wrong here.

No, nothing is wrong, since MSDOS.SYS is a binary file, it's completely normal that it looks that way. I think what ruthan meant was not edit the MSDOS.SYS file (which BTW, can't be edited with edit.com, it has to be edited with a hex editor), but instead edit the line where it is called in config.sys.

aha2940 wrote on 2020-03-25, 02:25:

EvieSigma wrote on 2020-03-25, 02:01:

I tried that but uh...something is wrong here. […]
Show full quote

ruthan wrote on 2020-03-24, 10:01:

There is simple solution edit msdos.sys add here Bootmenu=1 and reboot, select Command line only (it will bypass of loading of driver which im otherwise fill conventional mem).. after that navigate and run Hwinfo.

I tried that but uh...something is wrong here.

No, nothing is wrong, since MSDOS.SYS is a binary file, it's completely normal that it looks that way. I think what ruthan meant was not edit the MSDOS.SYS file (which BTW, can't be edited with edit.com, it has to be edited with a hex editor), but instead edit the line where it is called in config.sys.

That would certainly make more sense! I...don't know how to do that though. As in I don't know how I would edit said line.