[Ham-Computers] RE: Win98SE "Sleep" mode (LONG)

Hsu, Aaron [email protected]
Sun, 21 Apr 2002 13:32:09 -0700


Phil (et al),

The current chipset update on Intel's website supports everything back to the i82430TX which is a Pentium chipset.  I recently installed it on two i440BX based systems where some I/O devices were not being properly recognized.  You mentioned that you solved your situation by disabling the 2nd IDE controller.  I would say that you found a "work-around" and not a permanent solution.  It is well known that if you don't have the proper drivers (or .INF file) for your system's I/O controller, you will see symptoms similar to the ones your system is experiencing.  In a properly working system, you shouldn't have to disable anything in order to get something else working (unless there is some sort of *serious* resource conflict and a system board should not have resource conflicts "out-of-the-box").

Goto to http://www.intel.com, click on "Support" --> "downloads...for end users".  Then highlight "chipset software" on the left of the page and select "chipset software installation utility".  Select "Win98SE" as the operating system and click "Go".  It should come up with two utilities - the .INF Update and the Chipset ID util.  The .INF update is the one you should install and current version is 3.20.1008.  I'd cut-n-paste the link here, but it's WAY too long and would be "wrapped" by the e-mail editor.

Win98 (all flavors) have "generic" support for many chipsets.  However, much like any other software program out there, there's inevitably an update.  On most of the i440BX systems I've installed Win98SE on, Win98SE would not properly recognize all of the I/O devices until after the Intel .INF update.  There have also been chipset revision updates (Intel "stepping" levels) that require the .INF updates.  The chipsets have PnP ID's that are changed when updated and the older .INF files may not recognize the new PnP ID; or, it may recognize it, but not enable full functionality of the chip.

In your case, it's possible that the chipset "stepping" level is newer than what Win98SE supports "out-of-the-box".  This is where installing the latest .INF update will help.    Also realize that Win98(SE) does not support dual processors and may require the .INF update to recognize that the systemboard is configured for dual processors (however, Win98 still won't recognize the second processor, if installed).  In some multi-processor systemboard designs, it's possible to assign a processor specific functions, such as I/O only.  At the least with the .INF update you'll be up-to-date with the latest chipset support file(s).

And your question about the SCSI BIOS...SCSI BIOS' are usually "slow" to initialize (and Adaptec's BIOS is *REALLY* slow).  This is due to the bus scan and diagnostics the SCSI BIOS performs as part of it's startup.  SCSI is a high-performance, "intelligent" bus.  The SCSI BIOS performs several diagnostic checks on the bus, then goes out and scans for SCSI devices on the bus.  Narrow (8-bit data bus) SCSI supports 8 devices (7 + controller) and "Wide" (16-bit) SCSI supports 16 devices (15 + controller) and the SCSI BIOS scans each ID for a device.  As SCSI has matured, faster signaling rates were developed and the SCSI BIOS needs to check each ID at all of the supported signaling rates to ensure that a device wasn't missed.  This is generally why it takes so long for the SCSI BIOS to scan the SCSI bus.  The system BIOS is just waiting for the SCSI BIOS to complete it's scan.  I use an Adaptec RAID controller *and* an Adaptec 3950U2W with 2 SCSI channels and it takes almost a 2 minutes just to finish the SCSI bus scans!

IDE is much faster at this because IDE is *not* an "intelligent" bus.  It was (and still is) offically called ATAPI ("AT" attached peripherial interface).  This name comes from the old IBM AT...the original IDE interface was just an extension of the 16-bit ISA bus.  If you look at an original IDE adapter, it consisted of just a few TTL buffer chips.  The controller is actually on the drive itself and the adapter just extended the ISA bus to the drive (on current systems, there's a PCI to IDE "Host" controller that "converts the PCI bus to IDE).  Most of the signaling is still based on the old simple ST-506 command set with some enhancements along the way.  When the system BIOS scans for an IDE drive, it uses the old ST-506 style scan which just looks for a drive and initializes it when found...it really doesn't negotiate any specific data transfer rate (operating system device drivers do this - such as Bus Master IDE drivers for Windows).  Since ST-506 only supported 2 devices per bus, the scan is quick.  However, if you tell the BIOS that a drive is supposed to be on the IDE bus, but you don't physically have the drive there, the motherboard BIOS scan *will* try to detect the drive and it will "hang" there for a while as it tries to talk to the non-existant device.  It eventually gives up and you'll get a BIOS error that a drive wasn't found.  SCSI eventually just skips the device and moves on.


OK, back to the original issue.  I still *highly* recommend that you install the latest Intel chipset support software, v3.20.1008.  Intel also has a Bus Master IDE driver update, but this can often cause more problems and I don't recommend it unless you're really familiar with your system, IDE drives, and how to completely remove the driver from Win98(SE) if necessary.

73 & GL,

  - Aaron, NN6O