Attached is the log file from the latest DOS build. I have disabled CPU method 1, 2, 3 so that the SXL doesn't get reset.

IRQ's 10, 11, and 12 still show up as free, but they are in use. On this system, I can run hwinfo with all drivers loaded.

I like how hwinfo reads the keyboard controller brand. Any way to parse the model number as well? I have an HT6542B on that board.

The Mainboard Chipset information is incorrect. It is taking the name from the BIOS - Leading Edge Products, Inc. The chipset is ALi model M1429, revision A1.

feipoa wrote on 2020-04-18, 08:06:

Attached is the log file from the latest DOS build. I have disabled CPU method 1, 2, 3 so that the SXL doesn't get reset. […]
Show full quote

Attached is the log file from the latest DOS build. I have disabled CPU method 1, 2, 3 so that the SXL doesn't get reset.

IRQ's 10, 11, and 12 still show up as free, but they are in use. On this system, I can run hwinfo with all drivers loaded.

I like how hwinfo reads the keyboard controller brand. Any way to parse the model number as well? I have an HT6542B on that board.

The Mainboard Chipset information is incorrect. It is taking the name from the BIOS - Leading Edge Products, Inc. The chipset is ALi model M1429, revision A1.

Thanks!
The keyboard controller brand is the only thing I'm aware how to read.
Detecting ISA/VLB chipsets is quite problematic, similar to ISA cards (or older SIO chips), so each one requires a dedicated method which when attempted on a different chipset could cause overwriting of registers, crash, etc. Moreover, I don't have datasheets for most ISA/VLB chipsets 🙁 If you're aware of a collection of such documents, let me know and I will have a look at that.

I have about 50 or so datasheets saved for older systems, but it is not anywhere close to complete. Don't have the M1429 either :(

Are we finished with the SXL2 chip?

I decided to test HWiNFO on my AMI Mark V Baby Screamer motherboard, which contains an SXL2-66 upgrade. The report file started to get written, but it hung. If I run HWiNFO without the -r flag, the system hangs after viewing Peripherals Information and the PC speaker beeps rapidly without stopping.

feipoa wrote on 2020-04-18, 09:46:

I have about 50 or so datasheets saved for older systems, but it is not anywhere close to complete. Don't have the M1429 either 🙁

Are we finished with the SXL2 chip?

I'm interested in any datasheets 😉
I think I'm done with the SXL2 for now.

feipoa wrote on 2020-04-18, 10:05:

I decided to test HWiNFO on my AMI Mark V Baby Screamer motherboard, which contains an SXL2-66 upgrade. The report file started to get written, but it hung. If I run HWiNFO without the -r flag, the system hangs after viewing Peripherals Information and the PC speaker beeps rapidly without stopping.
SXL2-66_on_AMI_baby_screamer_motherboard.jpg
SXL2-66_on_AMI_baby_screamer_motherboard.log

If you run manually does it hang at the ISA screen too?
Do you have Win9x installed there too? I'd be interested in those reports too.

On my SXL2-66 system, I can boot to Win95c, NT 3.51, or NT4. But I can only boot to NT4 if the L1 cache is disabled and in 1x mode. Which OS would offer the most information?

Is this the ISA screen you are referring to? If so, it hangs on the second image below.

NT4 or Win95, probably won't be a big difference there. NT 3.5 isn't supported.
Check for VT83C461 is the problem, this is a slightly dangerous test and it seems to be causing issues on more systems. I will probably remove it entirely or make it disabled via a switch.
Is that SXL2 really running in 1x mode?

What is VT83C461? I don't see this chip on my MB. Image of the MB is here: http://mail.lipsia.de/~enigma/neu/pics/386babyscreamer.jpg

Dangerous as in it can damage my computer's hardware?

Is that SXL2 really running in 1x mode?

For my last test it was. I forgot to enable L1 and 2x mode after booting from a MS-DOS floppy. recall I need to boot from a MS-DOS floppy so I can load just HIMEM without having to REM'out a bunch of stuff in config.sys and autoexec.bat

feipoa wrote on 2020-04-18, 11:57:

What is VT83C461? I don't see this chip on my MB. Image of the MB is here: http://mail.lipsia.de/~enigma/neu/pics/386babyscreamer.jpg

Dangerous as in it can damage my computer's hardware?

It's an EIDE controller. No, it's not present on your system, but as I said earlier, detection of IDE/VLB adapters is usually done by probing IO locations to find specific patterns/registers of given adapter. There's no universal ID like in case of PCI that would be available on all adapters, instead each adapter uses a different set of IO ports and in a different way. So detection here is done by probing locations and the problem happens when a different adapter is using the same IO range but in a different way. To give you an example:
- Adapter A has port X (index), port X+1 (data). It has its own ID at index 0. So to read ID specific for A, you need to write 0 to X and read X+1.
- Adapter B has port X as config register. So if one probes for Adapter A and writes 0 to port X, it changes the config register contents.
There's no permanents damage possible, in worst case it's a crash or hang.

Here a build without the VT83C461 check:
[pulled, newer build available]

Thanks for the explanation!

Ran the new version, it hangs on creating a report file during ISA and other device scan.

If I run it in regular mode, still hangs up with perpheral information and keeps on beeping.

Previously it was hanging on "Checking: VIA VT83C461", which I removed entirely, so I'm wondering.. can you please try manually the ISA screen what's displayed in the bottom bar when it hangs?

This is what happens on the ISA section. The first time you run it, it detects the SCSI controller and the ethernet controller, but you cannot accesss the SCSI for more information. At this point, the SCSI HDD light stays lit up fully and doesn't go out until resetting the computer.

HWiNFO lets me press the left arrow button to go back out of there, I can then go back in, but only the ethernet controller shows. I can view the ethernet controller's detailed information, but SCSI is gone. When exiting HWiNFO, HDD cannot be accessed. Must reset.

This is all the time I have for today.

Hmm, that looks like the AHA-1540 check is causing a problem too.. It's quite odd as HWiNFO only issues an ID command to the SCSI controller, but it seems this somehow corrupts the controller state.
Oh, how I love detection of some ISA adapters 😁

The difference between the 1540C on the SXL2-66 systems and the 1522B on the SXL2-50 test bed is that the 1540C uses DMA, while the 1522B does not. Perhaps related to the problem, maybe not...

Here just another build with the AHA-1540 check removed too: [pulled, newer build available]
Going to continue work in the garden, will be back later...

Mumak wrote on 2020-04-18, 12:59:

Oh, how I love detection of some ISA adapters 😁

Yes, the PCI standard was so big step forward from legacy dark ages. Users cannot expect the detection of legacy HW will work accurate & reliable. It's a trade off. Too excesive probing can cause corruption of other HW that was not intended doing so, too safe probing will miss-detect some HW, this will be endless debugging (esp. without having the target HW available for coding and testing)...

RayeR wrote on 2020-04-18, 19:57:

Users cannot expect the detection of legacy HW will work accurate & reliable. It's a trade off. Too excesive probing can cause corruption of other HW that was not intended doing so, too safe probing will miss-detect some HW, this will be endless debugging (esp. without having the target HW available for coding and testing)...

That's what it is starting to look like. It would probably take 3 years to test and debug all my pre-PCI hardware with 4-hour testing windows. On the bright side, 386/486 ISA and VLB hardware is pretty popular on Vogons and a DOS utility which can detect this hardware correctly is of interest. I don't recall how well other DOS diagnostic utilities, like CheckIt Pro, Dr. Hardware, PC Check, Norton Sysinfo, NSSI, Syschk, etc. detect hardware, but I will look into it.

feipoa wrote on 2020-04-18, 22:53:

RayeR wrote on 2020-04-18, 19:57:

Users cannot expect the detection of legacy HW will work accurate & reliable. It's a trade off. Too excesive probing can cause corruption of other HW that was not intended doing so, too safe probing will miss-detect some HW, this will be endless debugging (esp. without having the target HW available for coding and testing)...

That's what it is starting to look like. It would probably take 3 years to test and debug all my pre-PCI hardware with 4-hour testing windows. On the bright side, 386/486 ISA and VLB hardware is pretty popular on Vogons and a DOS utility which can detect this hardware correctly is of interest. I don't recall how well other DOS diagnostic utilities, like CheckIt Pro, Dr. Hardware, PC Check, Norton Sysinfo, NSSI, Syschk, etc. detect hardware, but I will look into it.

I doubt other tools were digging so deep. Usually only common stuff, i.e. cards like SB-compatible, Adlib, MPU, often just via env. variables.. I doubt they can issue a CPU reset to read the CPU ID, not even sure if they can enum PnP cards, etc.. I have code to detect lots of HW but as you've seen, sometimes I need to scrap that for the sake of stability.