feipoa wrote on 2020-04-15, 10:33:

Not sure what to say about that. Symptoms occur on both Cx5x86 systems. I did try it with all 0's in the ini file, but it stil […]
Show full quote

Not sure what to say about that. Symptoms occur on both Cx5x86 systems. I did try it with all 0's in the ini file, but it still hangs.

On a different note, I saw this comment,

Mumak wrote on 2020-03-19, 15:25:

Thanks for the feedback. ... It would be even better if I could tell the TI486DLC from Cx486S, but I'm not sure if this is possible at all.

And recalled that the Cx486s has 2 KB of cache, while the DLC has 1 kb. Can you use the cache size difference as an aid here?

One question - do you have HIMEM.SYS loaded ? I have been able to reproduce the same type of crash on my (dual-P5) system when I don't load HIMEM.SYS
EDIT: I think I solved the bug when not using XMS manager, so please try this build: [pulled, newer build available]
In case XMS manager wasn't the issue, it might provide me some additional debug messages when it hangs.

Himem was not loaded. Only the bare minimum is loaded: download/file.php?id=80550&mode=view

feipoa wrote on 2020-04-15, 22:46:

Himem was not loaded. Only the bare minimum is loaded: download/file.php?id=80550&mode=view

OK, that explains it finally 😀 I was searching for something related to 5x86 code and it turns out the problem was in fact my own XMS memory management..
Waiting what the new test will show 😀

I receive a not enough memory error, but it no longer hangs. Pressing Q to Quit works now.

feipoa wrote on 2020-04-16, 07:21:

I receive a not enough memory error, but it no longer hangs. Pressing Q to Quit works now.
IMG_4660.jpg

That's great news finally! 😀
Try to load HIMEM.SYS and set DOS=HIGH, that should make enough memory.

HWiNFO DOS report enclosed. Some observations:

615 KB of free conventional memory was needed to run the hwinfo.exe -r to generate the report. I tried it with 589 KB free, but received an error.
589 KB of free conventional memory was needed to run hwinfo.exe

The amount of conventional memory needed may limit the usefulness. I had to REM a lot of entries to be able to run DOS and just HIMEM. Much easier to boot to DOS without HIMEM (press 7 at boot prompt). Do you know how to add a boot menu option to boot into DOS with just HIMEM?

With my drivers loaded, I have only 500 KB of free conventional memory. Is there any means to get the program to run with just 500 KB free? Memory extenders?

Mainboard Info showed that IRQ's 10, 11, 14, and 15 are free. The only one which I think should be free is IRQ 15 (secondary port for the onboard IDE controller is disabled in the BIOS). IRQ 11 is the SCSI controller, IRQ 14 is the primary port for the onboard IDE controller, IRQ 10 is the Voodoo3, but I'm not sure if the BIOS is assigning this or Windows. The BIOS option to "Assign IRQ for VGA" is not in this particular BIOS, so it may be enabled by default, or not at all. But I'm positive that IRQ 11 is assigned to the SCSI controller as it is listed in the SCSI card's BIOS. IRQ 14 should be assigned, although there is no IDE drive connected to the primary IDE port.

Drive Info - Capacity is incorrect. Capacity is limited to typical BIOS limitations at the time, or 8,032 MByte. I believe the HDD size is 36 MByte. I tried running HWiNFO with the SCSI card's DOS driver installed and without, but capacity is still read as 8,032 MByte in HWiNFO.

ISA bus information shows "no devices/cards", which isn't correct. There's a sound card, network card, and game port card plugged into the ISA slots.

Stepping information is not properly displayed for the Cyrix 5x86. It is reading the HEX properly for the device ID registers, but it would be nice to display that in typical human readable terms. If my memory is correct, stepping is taken from DIR1 (Device ID1) and is the highest order nibble (the four highest order bits), while the revision is also from DIR1, but is the lowest order nibble. So if DIR1 = 00000101, the 1st four 0's is the stepping once converted to DEC,w hile the 0101 is the revision, once converted to DEC. DIR0 is the current multiplier setting.

feipoa wrote on 2020-04-16, 09:24:

HWiNFO DOS report enclosed. Some observations: […]
Show full quote

HWiNFO DOS report enclosed. Some observations:

615 KB of free conventional memory was needed to run the hwinfo.exe -r to generate the report. I tried it with 589 KB free, but received an error.
589 KB of free conventional memory was needed to run hwinfo.exe

The amount of conventional memory needed may limit the usefulness. I had to REM a lot of entries to be able to run DOS and just HIMEM. Much easier to boot to DOS without HIMEM (press 7 at boot prompt). Do you know how to add a boot menu option to boot into DOS with just HIMEM?

With my drivers loaded, I have only 500 KB of free conventional memory. Is there any means to get the program to run with just 500 KB free? Memory extenders?

Mainboard Info showed that IRQ's 10, 11, 14, and 15 are free. The only one which I think should be free is IRQ 15 (secondary port for the onboard IDE controller is disabled in the BIOS). IRQ 11 is the SCSI controller, IRQ 14 is the primary port for the onboard IDE controller, IRQ 10 is the Voodoo3, but I'm not sure if the BIOS is assigning this or Windows. The BIOS option to "Assign IRQ for VGA" is not in this particular BIOS, so it may be enabled by default, or not at all. But I'm positive that IRQ 11 is assigned to the SCSI controller as it is listed in the SCSI card's BIOS. IRQ 14 should be assigned, although there is no IDE drive connected to the primary IDE port.

Drive Info - Capacity is incorrect. Capacity is limited to typical BIOS limitations at the time, or 8,032 MByte. I believe the HDD size is 36 MByte. I tried running HWiNFO with the SCSI card's DOS driver installed and without, but capacity is still read as 8,032 MByte in HWiNFO.

ISA bus information shows "no devices/cards", which isn't correct. There's a sound card, network card, and game port card plugged into the ISA slots.

Stepping information is not properly displayed for the Cyrix 5x86. It is reading the HEX properly for the device ID registers, but it would be nice to display that in typical human readable terms. If my memory is correct, stepping is taken from DIR1 (Device ID1) and is the highest order nibble (the four highest order bits), while the revision is also from DIR1, but is the lowest order nibble. So if DIR1 = 00000101, the 1st four 0's is the stepping once converted to DEC,w hile the 0101 is the revision, once converted to DEC. DIR0 is the current multiplier setting.

Thanks for the extensive report!
I have already talked a few times regarding the relatively high memory footprint of HWINFO. Unfortunately a PMODE extender is currently not an option for me as this would be a high effort with potential troubles to be expected (access to certain hardware and the PMODE in DOS itself). Instead I'm working on optimizing the code since I re-launched the tool and I have already been able to save dozens of KB, this work is still in progress. Perhaps at sometime later I will check overlays if I can find a reasonable way how to split the code... I think that most users have HIMEM loaded (which is strongly recommended) and if you do so and load all drivers high, there should be no issue here.

Regarding the other issues you found.. I will completely revamp reporting of Cyrix stepping/revision IDs, there also seems to be some bug preventing reporting of correct PCI IRQs in the list, I will have a look at that too.
The ISA menu is quite limited and reports only certain adapters. This is because detection of such cards is quite tricky and each every one needs special code, which can be sometimes dangerous to check for.. PnP-capable devices are reported in the respective section and not duplicated in the ISA section, neither ISA sound cards, which are shown in the Peripherals section.

Drive capacity for ATA drives should not be truncated as these are directly queried (not via BIOS). For SCSI I recommend to install the ASPI driver (which can be loaded high as well).

I will soon provide a new version to test as I resolve at least most of the issues found.

I have a lot loaded high already. If I'm not mistaken, I think some devices cannot be loaded high?

Do you have any recommendation for my system:

AUTOEXEC.BAT

1LH /L:2 C:\MSCDEX /D:ASPICD0 /M:15 /E /S /V
2MODE CON CODEPAGE PREPARE=((850) C:\WINDOWS\COMMAND\EGA.CPI)
3MODE CON CODEPAGE SELECT=850
4LH MOUSE
5SET PATH=C:\WINDOWS\SYSTEM\WBEM;%PATH%;C:\
6SET DIRCMD=/P /A
7SET TEMP=C:\WINDOWS\TEMP
8SET TMP=C:\WINDOWS\TEMP
9@ECHO ON
10@ECHO.................................................................................
11@ECHO Loading Cyrix 5x86 Registers
125x86.exe /LSSER=off /FP_FAST=on /RSTK_EN=on /MEM_BYP=on /DTE_EN=on /BWRT=on /LINBRST=off /LOOP_EN=on /BTB_EN=off
13@ECHO Type BTBon/BTBoff to turn ON/OFF branch prediction
14@ECHO.................................................................................
15@ECHO OFF
16SET BLASTER=A220 I5 D1 H5 P330 E620 T6 J0
17UNISOUND.COM /V99
18C:\PROGRA~1\CREATIVE\CTSND\MIXERSET.EXE /LI:224 /CD:224
19C:\CHJOY3.EXE

CONFIG.SYS

1DOS=HIGH,UMB,NOAUTO
2LASTDRIVE=E
3COUNTRY=004,850,C:\WINDOWS\COMMAND\COUNTRY.SYS
4DEVICE=C:\WINDOWS\HIMEM.SYS /V
5REM DEVICE=C:\WINDOWS\EMM386.EXE RAM /MIN=0 I=B000-B7FF /V
6DEVICEHIGH /L:2 =C:\WINDOWS\COMMAND\DISPLAY.SYS CON=(EGA,,1)
7DEVICEHIGH /L:2 =C:\ASPI8U2.SYS /D /P140 /Q10
8DEVICEHIGH /L:2 =C:\ASPICD.SYS /D:ASPICD0
9DEVICE=C:\WINDOWS\IFSHLP.SYS
10SHELL=C:\WINDOWS\COMMAND.COM C:\WINDOWS\ /E:1024 /P

I'm not sure if unisound (sound card drivers), chjoy3 (sets timing for gameport card), mixerset (sets sound card input volumes), or IFSHLP can be loaded high. It is possible I've tried it before, but don't recall. I can test them one by one again. With my autoexec and config files as is, I have only 500,192 KB free of conventional memory. Seems unlikely I'll be able to free up the 600+ KB required.

What ASPI driver are you refering to for SCSI in DOS. I usually install the ASPI package for Windows, e.g. filename ASPI-v471a2.exe I wasn't aware there was one for DOS. ASPI8U2.SYS incorrect for DOS?

feipoa wrote on 2020-04-16, 10:28:

I have a lot loaded high already. If I'm not mistaken, I think some devices cannot be loaded high? […]
Show full quote

I have a lot loaded high already. If I'm not mistaken, I think some devices cannot be loaded high?

Do you have any recommendation for my system:

AUTOEXEC.BAT

Copy code to clipboard

1LH /L:2 C:\MSCDEX /D:ASPICD0 /M:15 /E /S /V
2MODE CON CODEPAGE PREPARE=((850) C:\WINDOWS\COMMAND\EGA.CPI)
3MODE CON CODEPAGE SELECT=850
4LH MOUSE
5SET PATH=C:\WINDOWS\SYSTEM\WBEM;%PATH%;C:\
6SET DIRCMD=/P /A
7SET TEMP=C:\WINDOWS\TEMP
8SET TMP=C:\WINDOWS\TEMP
9@ECHO ON
10@ECHO.................................................................................
11@ECHO Loading Cyrix 5x86 Registers
125x86.exe /LSSER=off /FP_FAST=on /RSTK_EN=on /MEM_BYP=on /DTE_EN=on /BWRT=on /LINBRST=off /LOOP_EN=on /BTB_EN=off
13@ECHO Type BTBon/BTBoff to turn ON/OFF branch prediction
14@ECHO.................................................................................
15@ECHO OFF
16SET BLASTER=A220 I5 D1 H5 P330 E620 T6 J0
17UNISOUND.COM /V99
18C:\PROGRA~1\CREATIVE\CTSND\MIXERSET.EXE /LI:224 /CD:224
19C:\CHJOY3.EXE

CONFIG.SYS

Copy code to clipboard

1DOS=HIGH,UMB,NOAUTO
2LASTDRIVE=E
3COUNTRY=004,850,C:\WINDOWS\COMMAND\COUNTRY.SYS
4DEVICE=C:\WINDOWS\HIMEM.SYS /V
5REM DEVICE=C:\WINDOWS\EMM386.EXE RAM /MIN=0 I=B000-B7FF /V
6DEVICEHIGH /L:2 =C:\WINDOWS\COMMAND\DISPLAY.SYS CON=(EGA,,1)
7DEVICEHIGH /L:2 =C:\ASPI8U2.SYS /D /P140 /Q10
8DEVICEHIGH /L:2 =C:\ASPICD.SYS /D:ASPICD0
9DEVICE=C:\WINDOWS\IFSHLP.SYS
10SHELL=C:\WINDOWS\COMMAND.COM C:\WINDOWS\ /E:1024 /P

I'm not sure if unisound (sound card drivers), chjoy3 (sets timing for gameport card), mixerset (sets sound card input volumes), or IFSHLP can be loaded high. It is possible I've tried it before, but don't recall. I can test them one by one again. With my autoexec and config files as is, I have only 500,192 KB free of conventional memory. Seems unlikely I'll be able to free up the 600+ KB required.

What ASPI driver are you refering to for SCSI in DOS. I usually install the ASPI package for Windows, e.g. filename ASPI-v471a2.exe I wasn't aware there was one for DOS. ASPI8U2.SYS incorrect for DOS?

You indeed seem to have most devices loaded high already so I'm wondering why only 500KB are left. Something must be eating quite much there.. You'll need to check the actual memory map to see what's taking so much RAM in the low area... Sorry, but I don't have experience with those sound drivers, so can't make recommendations.
Adaptec has ASPI packages for DOS/Win3x, but I don't recall which one I used, I don't have it archived anymore. I just load "ASPI8DOS.SYS" high on my AHA-2940U/UW and it works well.

ASPI8DOS.SYS is the SCSI DOS driver for the 2940UW, while ASPI8U2 is the driver for the AHA-2940U2W. According to the Adaptec readme, these are the ASPI managers/drivers. So not sure why HWiNFO isn't reading the full size of my HDD.

Attached is the screenshot after running mem /c /p

Why aren't these device drivers being loaded high?

EDIT: I have edited the IFSHLP line to DEVICEHIGH /L:1 =C:\WINDOWS\IFSHLP.SYS , but the same 500,192 KB is free.

feipoa wrote on 2020-04-16, 11:04:

ASPI8DOS.SYS is the SCSI DOS driver for the 2940UW, while ASPI8U2 is the driver for the AHA-2940U2W. According to the Adaptec r […]
Show full quote

ASPI8DOS.SYS is the SCSI DOS driver for the 2940UW, while ASPI8U2 is the driver for the AHA-2940U2W. According to the Adaptec readme, these are the ASPI managers/drivers. So not sure why HWiNFO isn't reading the full size of my HDD.

Attached is the screenshot after running mem /c /p
mem-c.jpg

Why aren't these device drivers being loaded high?

If ASPI DOS drivers are properly installed, the "SCSI info" menu item in HWiNFO should be accessible and provide details about the host adapter and all SCSI devices. I guess something isn't working right here.. When the ASPI driver starts do you see a message that it's correctly installed?

Not sure why nothing gets loaded high, just some clues how I have this set up:
- I specify DOS=HIGH after loading HIMEM.SYS, not sure if that makes any difference. IDK what the NOAUTO switch does, but I also think that UMB has a meaning only for EMM386. I'd suggest to do just DOS=HIGH
- I don't use /L: parameter for DEVICEHIGH, try without it as well.
- You might also add /TESTMEM:OFF to loading HIMEM.SYS, that will speed-up the start. Perhaps remove the /V (verbose) switch to see if it doesn't report some error.

OK, I have some testing to do then.

I tried it with EMM386 enabled and most drivers load high. Not mouse or ASPI though.

NOAUTO:

1NOAUTO makes it possible to load drivers and TSR programs in conventional memory, if wanted - otherwise DOS 7.x always tries to load in Upper Memory, even though DEVICEHIGH, FILESHIGH etc. has not been used.  Some drivers can only work if loaded low with a DEVICE command.

UMB:

1UMB allows the use of Upper Memory Blocks for resident drivers and programs (requires an EMS manager, e.g. EMM386).  This frees up more conventional memory for your applications.

Hm, it looks like with pure XMS manager (HIMEM.SYS + DOS=HIGH) only certain portions of DOS can be loaded into HMA. Loading the rest of drivers/TSRs requires EMM386 which are then residing in UMB.
Lot of things that I forgot over the time 😁

Yeah, EMM386 is needed it seems. If I use EMM386 and run HWiNFO, I get a warning stating that HWiNFO is run under Windows 95. Some features might not work, and for more accurate information, to not use EMM386. But it seems to work for the most part.

Back your question about the SCSI hard drive. If I view the hard drive under SCSI info, I can see the full size of the HDD, the vendor, etc. The area in which I am only seeing 8 GB is under the Drive Info tab.

The warning you get is because the system runs in V86 mode and in this case HWiNFO can't perform some low-level checks. So it might not be able to retrieve certain information.
This is usually the case of Win95 systems. EMM386, some other EMS managers and Win98 DOS on the other hand offer methods to temporary gain low-level control, which is also used by HWiNFO.

Great that you managed to get ASPI working, that should be well covered in HWiNFO included larger sizes. The 'classic' drive tab for SCSI goes via BIOS, hence the limit.

feipoa, did you tried to load UMBPCI.SYS ( https://www.uwe-sieber.de/umbpci_e.html ) with himem.sys in config.sys? It would enable you UMB without virtual mode like EMM386. But I don't know if your chipset is supported, I only use it on newer intel-based machines. Just give a try...

OK, so here a new build with:
- Updated reporting of Cyrix stepping/revision ID. Although some documents are not clear about their meaning, i.e. for 5x86 stepping=1 means "1", some others say it's "2.x".
- Updated reporting of IRQ/DMA list to properly list some PCI devices claimed
- Fixed a bug in FPU detection code (no FPU)
- Some small reduction in memory usage
Could you please re-test using this build:
[pulled, newer build available]

I tried your new 6.05 above, and it reports more CPU information (frequencies and cores) than previous 6.04, but still does not detect my CPU as the correct i7 Broadwell family, says unknown p6 generation. I've an i7-5500u chip in this laptop, which has a nominal core clock of 2400 Mhz and peak of 3000 Mhz. Logfile attached. Also the screen freezes, goes black, when "Detecting video information", and I must reboot in order to regain use of the system. The accompanying onboard graphics chipset is: Intel HD Graphics 5500 (300 - 950 MHz). Somehow the detection routines affect the text screen memory, and overwrite the screen, is my theory. I belive the 6.03 version did not have this issue, and with it also it detected the built-in laptop display, as well, but with your new 6.05, I can't obtain this information. Any thoughts?

zyzzle wrote on 2020-04-17, 03:43:

I tried your new 6.05 above, and it reports more CPU information (frequencies and cores) than previous 6.04, but still does not detect my CPU as the correct i7 Broadwell family, says unknown p6 generation. I've an i7-5500u chip in this laptop, which has a nominal core clock of 2400 Mhz and peak of 3000 Mhz. Logfile attached. Also the screen freezes, goes black, when "Detecting video information", and I must reboot in order to regain use of the system. The accompanying onboard graphics chipset is: Intel HD Graphics 5500 (300 - 950 MHz). Somehow the detection routines affect the text screen memory, and overwrite the screen, is my theory. I belive the 6.03 version did not have this issue, and with it also it detected the built-in laptop display, as well, but with your new 6.05, I can't obtain this information. Any thoughts?

I will try to fix both issues in the next build, but please see my previous comments regarding support of such modern systems in DOS.

RayeR wrote on 2020-04-16, 14:15:

feipoa, did you tried to load UMBPCI.SYS ( https://www.uwe-sieber.de/umbpci_e.html ) with himem.sys in config.sys? It would enable you UMB without virtual mode like EMM386. But I don't know if your chipset is supported, I only use it on newer intel-based machines. Just give a try...

I haven't, but the website says this about 486's with PCI:

Generally it seems that UMBPCI doesn't work on 486 class computers even they have a PCI chipset. That's because their PCI BIOS doesn't support read and write access to the PCI configuration registers.

I guess I'll have to test HWiNFO with EMM386 running. I set LASTDRIVEHIGH, which bumped my free conventional memory up to 593 KB.