While this book presents many important PC technologies and bus schemes, there are always a number of emerging interfaces - both software and hardware based - designed to streamline the performance and usability of the personal computer. Most new interfaces and technologies are designed around four key areas of the PC; improving graphics performance (AGP), improving power management (ACPI, APM, Instant ON, SMBus), simplifying connections and improving the performance of peripheral devices (Device Bay, I²O, USB), and improving the utilization of PCs (DMI, IrDA). Many of these emerging standards come from the PC industry leaders such as Intel, Compaq, and Microsoft, while other standards are evolving from industry Special Interest Groups (SIGs) like the Desktop Management Task Force (or DTMF). Virtually all current PCs support one or more of these new standards to some degree, so as a technician, you should at least be familiar with the benefits and features each one offers. This chapter presents an overview of these new interfaces and technologies, and offers some resources for more detailed study.

One of the major drawbacks to older power management schemes has been that "system events" (i.e. Plug-and-Play events) are largely overlooked if the system happens to be in a power-saving mode while the event takes place. In many cases, this could also result in a system crash or other system problem. Intel, Microsoft, and Toshiba have banded together to develop ACPI (Advanced Configuration and Power Interface) standard. The ACPI interface is largely a software feature incorporated into new operating systems (i.e. Windows 95) which gives the operating system direct control over both the power management and Plug-and-Play functions of a computer. When the operating system loads, the ACPI feature takes over the power management functions (such as APM) and PnP functions from the existing BIOS. Once the OS takes over, it handles all the PnP events, power management, and thermal states (based on user settings and requests made by individual applications). The ACPI interface effects many areas of the contemporary PC:

• System power management - ACPI defines the techniques for putting the whole computer in to and out of system "sleeping" states. It also provides a general mechanism for any device to "wake" the computer as needed.
• Device power management - ACPI tables describe motherboard devices, their power states, the power
• planes the devices are connected to, and controls for putting devices into different power states. This enables the OS to put various devices into low-power states based on application usage. In other words, devices which are not being used by an application can be placed into low-power states, while devices which are being used can be kept active.
• Processor power management - While the OS is idle (but not sleeping), it will use commands described by the ACPI standard to put processors in low-power states.
• Plug-and-Play - ACPI specifies the techniques used to enumerate and configure motherboard devices. This information is arranged hierarchically, so when events such as docking and undocking take place, the operating system has precise, knowledge of which devices are affected by the event.
• System events - ACPI provides a "general event" mechanism that can be used to keep track of thermal events, power management events, docking, device insertion and removal, etc. This mechanism is very flexible in that it does not define specifically how events are routed to the core logic chipset. This allows individual device makers to incorporate their own responses to system events.
• Battery management - For portable computers, battery management policy moves from the APM BIOS to the ACPI operating system. The OS determines the "low battery" and "battery warning" points, and the OS also calculates the battery remaining capacity and remaining battery life. An ACPI-compatible battery device needs either a Smart Battery subsystem interface (SMbus), which is controlled by the OS directly through the embedded controller interface, or a Control Method Battery (CMBatt) interface.
• Thermal management - Since the ACPI OS controls the power states of devices and processors, ACPI also addresses system thermal management. It provides a simple, direct approach that allows manufacturers to define thermal zones, thermal indicators, and methods for cooling thermal zones.
• Embedded controller - ACPI defines a standard hardware and software communications interface
• between an OS bus enumerator and an embedded controller. This allows any OS to provide a standard bus enumerator that can directly communicate with an embedded controller in the system, thus allowing other drivers within the system to communicate with and use the resources of system embedded controllers. This then enables an OEM to provide platform features that the OS and applications can use.
• System Management Bus controller - ACPI defines a standard hardware and software communications interface between an OS bus driver and an SMBus controller. This allows any OS to provide a standard bus driver that can directly communicate with SMBus devices in the system. This then enables an OEM to provide platform features that the OS and applications can use.

ACPI support is provided at the hardware and software level in a PC. At the hardware level, you’ll need a motherboard with an ACPI compliant chipset, as well as ACPI compliant devices. For software, you’ll need an ACPI operating system (such as Windows 95), and perhaps an ACPI driver. Many of the newest PCs are now supporting ACPI. Keep in mind that using "legacy" devices may sometimes result in power management or Plug-and-Play problems under ACPI.

Today, 3D rendering is considered to be more of a necessity than an option, and is used extensively in games and all types of presentation and CAD software. The problems with 3D technology is that it requires intensive processing, and lots of memory. This places a lot of strain on ordinary 3D video cards that use the PCI bus - their performance is often limited because of the massive amounts of data that must be passed between the video card and main memory. The AGP (Accelerated Graphics Port) developed by Intel uses a variation of the PCI bus slot to provide a high-speed data pathway between the 3D video card and main memory, and allows the AGP video card to utilize main memory for graphics purposes.

A prime example of AGPs potential is in the use of "surface textures". Ordinarily, textures (the "painted" surfaces you see in so many 3D walk-through games like Quake II) are stored in the memory on a video card. This demands a lot of memory because texture maps are basically images, and textures are usually drawn in low-resolution to save space (which explains why so many scenes appear grainy when you get close to them). By moving the texture maps to main system RAM and accessing them across the AGP, it is possible to accelerate graphics performance because the 3D rendering engine can focus on rendering rather than patching in textures. The textures can also be made larger and at higher resolutions because there is typically much more main RAM available than graphics card memory. In actual practice, other graphics-related data can also be moved to main memory through the AGP.

The AGP interface specification uses the 66MHz PCI specification (Revision 2.1) as a baseline, and adds three significant performance extensions - or enhancements - which are intended to optimize the AGP for high-performance 3D graphics applications (these AGP extensions are NOT described in, or required by, the PCI specification 2.1). These extensions are:

• Deeply pipelined memory read and write operations which fully hide memory access latency.
• Demultiplexing of address and data on the bus, allowing almost 100% bus efficiency.
• Timing for 133MHz data transfer rates, allowing for real data throughput in excess of 500MB/sec.

The high-speed AGP is physically, logically, and electrically independent of the PCI bus. It is an additional expansion bus in the system as shown in Fig. 36-1 which is intended for the exclusive use of visual display devices - all other I/O devices (such as drive controllers) will remain on the PCI bus. The add-in slot defined for AGP uses a new connector body (for electrical signaling reasons) which is not compatible with the PCI connector, so PCI and AGP boards are not mechanically interchangeable. The pinout for an AGP slot is listed in Table 36-1.

NOTE: Though the AGP interface is based on the PCI bus, it was developed by Intel (independent of the PCI Special Interest Group) and has neither been reviewed nor endorsed by that group.

Implementing AGP on the desktop requires support from the latest hardware. You’ll need a motherboard (often a Pentium II ATX or NLX motherboard) with a recent chipset that supports an AGP slot, as well as an AGP video adapter (i.e. one of the Matrox AGP video cards). With the suitable hardware available, you’ll need a video driver for Windows 95.

Power management has become a serious concern for both desktop and mobile computers alike. The sheer volume of desktop PCs in service today accounts for a substantial percentage of all energy consumption, so power management techniques can reduce those energy demands (and costs). For mobile PCs, power management helps to extend battery life by powering down idle systems. The APM

(Advanced Power Management) specification authored by Intel and Microsoft represents the first concerted effort to define the role and actions of system-wide power management in the PC. APM is a software approach involving BIOS, the operating system, device drivers, and the devices themselves. When properly implemented, APM can control the system through five power modes; on, enabled, standby, suspend, and off. Table 36-2 outlines the system conditions in each APM state.

In order for APM to function properly, three essential elements are needed (as shown in Fig. 36-2); the BIOS layer, the operating system layer, and the application layer. The following sections outline the operation of each element.

The BIOS layer - The APM BIOS is the lowest level of power management software in the PC, and it interfaces directly to suitable "power managed" system motherboard hardware. The APM BIOS is supplied by the OEM and is specific to the hardware platform. An APM BIOS may provide some degree of power management functionality without any support from operating system or application software (the OEM or BIOS provider determines just how much power management functionality is implemented by the APM BIOS in a stand-alone configuration). The APM BIOS stand-alone power management functions are enhanced once an APM driver establishes a "connection" with the APM BIOS. Once made, this "connection" establishes a protocol that allows the firmware to communicate power management events to the APM driver, and to wait for APM driver acknowledgment if necessary.

The operating system layer - The APM driver has three primary power management functions; (1) passing calls and information between the application and APM BIOS layers, (2) arbitrating application power management calls in a multitasking environment, and (3) identifying power saving opportunities not apparent at the application or BIOS layer. An APM "connection" must be established between the APM BIOS and an APM driver for optimum system power management.

By regularly polling the APM BIOS, the APM driver will determine whether the APM BIOS wants a power saving state to occur. In the case of a Standby or Suspend request, the APM driver is expected to do the appropriate processing to prepare for the state change, and then call the APM BIOS to actually execute the power state change in hardware. Since only one APM driver can exist in the system (and there may be many APM applications), the APM driver must provide an interface between the APM BIOS and APM-aware applications. This interface should pass the application’s APM requests to the APM BIOS, and send any APM BIOS-generated events back to the applications. Each APM driver should specify a power management application-to-OS interface.

The application layer - APM-aware applications assist in power management by providing information that only the application is in a position to know (or easily determine). Similarly, device drivers for add-in devices which are not under direct control of the BIOS (such as PCMCIA cards or ISA video adapters) may be able to manage power on their device given suitable information about the overall system state, or by monitoring usage of their own hardware. Applications and device drivers are not required to be APM-aware, but they can greatly increase APM effectiveness - particularly on less sophisticated operating systems. Under DOS, the application or device driver is often in the best position to know when the application or an add-in device is idle and awaiting further activity.

APM-aware applications register with the APM driver using an operating system dependent mechanism. The APM driver notifies registered applications and device drivers when system power management events occur, and the applications and device drivers then take suitable action. For example, when an APM-aware device driver learns from the APM driver that the system will be suspended, it saves device information to be restored when the system resumes. When an APM-aware device driver is notified that the system has resumed, it restores the add-in device to its previous operating state.

APM requires four elements to function properly; an APM BIOS, an APM operating system (i.e. Windows 95), power manageable devices, and APM device drivers to operate those devices. Most Pentium and Pentium MMX PCs support APM, though the very newest PCs (i.e. Pentium II systems) are implementing ACPI support instead of APM.

Now in version 1.2, it is unlikely that the APM specification will continue to develop as a stand-alone technology. The reason for this is that APM techniques are known to interfere with some Plug-and-Play devices (especially PC Card swapping and mobile PC docking and undocking operations). Rather than continue developing APM, the role of APM has been expanded and combined with PnP operations in the ACPI standard (see the ACPI section in this chapter).

Adding or replacing a drive on a PC continues to be a fairly labor-intensive process. Even with the benefits of automated device detection and driver installation offered by Windows 95, it is still necessary for users or technicians to physically open the system and manually install or replace any given device. In order to simplify system assembly, maintenance, and expansion, designers have introduced the Device Bay - an industry specification for interchangeable peripheral devices (such as hard disk drives, modems, network adapters, CD-ROM drives, DVD-ROM drives, and a variety of other electronic devices). When fully implemented, you should simply insert a peripheral (i.e. a DVD-ROM) into the PC without opening, rebooting, or even powering down the PC. The system would then recognize the new or replaced device, and automatically reconfigure the system to accommodate it. Device Bay is expected to use a combination of USB port for hot-swappable, medium-speed serial data, and IEEE 1394 "Fire Wire" for high-speed serial data. In addition, the Device Bay will accommodate staged power management (compatible with ACPI).

In order to implement the Device Bay, you’ll need a Device Bay-compliant operating system, Device Bay devices, and a Device Bay-compliant motherboard, BIOS, and chipset. You’ll also need a case that provides Device Bay slots and connectors. As of this edition, the Device Bay specification is finalized, but actual Device Bay systems are not yet available - largely because of the slow adoption of IEEE 1394 and the poor industry response to USB (both of which have delayed the appearance of Device Bay-compliant drives). Intel has yet to release a Device Bay-compliant chipset, and Microsoft has not yet released the next version of Windows (i.e. Windows 98) which should include support needed for Device Bay operation.

If you’ve been in the PC industry for any period of time, you know how much PC hardware has proliferated. Just take a stroll through any computer super-store such as CompUSA or Computer City, and you’ll see a vast array of devices - there are literally dozens of options to choose from in everything from cases to CD-ROM drives and sound cards. You can also see this range of products in the myriad of PCs now in the market. Unfortunately, there is a problem with all of this diversity - it is VERY difficult to manage from the technical standpoint. In other words, it’s hard to find out about what’s inside any given PC. There ARE diagnostics which can identify some parts, but diagnostics are not always reliable, and they are obsolete soon after new products arrive. Diagnostics also don’t provide useful information about when products were installed or upgraded, or what versions of drivers are in use. This often means that a technician must work "in the dark". When you consider that some corporate environments may have hundreds (perhaps thousands) of computers that must be networked and supported, you can imagine how daunting the task of equipment management can be for managers and technicians alike.

The Desktop Management Task Force (DTMF) has developed the Desktop Management Interface (DMI) as a solution to this "information gap". The DMI is a software standard for describing and accessing information about all types of PCs and PC components. The DMI standard provides a common resource for tech support, IT managers, and individual users to access information about all aspects of a given PC - including processor type, installation date, attached printers and other peripherals, power sources, and maintenance history. The DMI provides support for describing the more than 80,000 PC products in the marketplace today, allowing more cost-effective (and less "crisis-driven") PC management and support. Current versions of DMI also allow technicians to troubleshoot remote PCs right over a network from their own desktop PC.

DMTF working committees create standardized DMI data-models in the .MIF (Management Information Format) file format to make it easier for vendors to implement the DMI standard in different product categories. For example, DMTF working committees have described standard sets of manageable attributes in model .MIF files for products such as PC systems, servers, printers, LAN adapters, modems, software applications, and mobile devices. To make a product DMI-enabled, vendors can code in the appropriate .MIF file with information about their specific product and create "instrumentation code" to handle DMI information.

Now at version 2.0, the DMI is a software standard which requires a "service layer" of software under the operating system, as well as DMI-enabled products (devices with .MIF files already prepared). DMI will work under Windows 95, and many major system manufacturers (such as Compaq, Dell, HP, IBM, NEC, and Sun) are now producing DMI-compliant systems. There are now about 200-300 DMI-enabled devices. As more devices are "instrumented" for DMI, it is very probable that DMI-enabled systems will become more popular.

For an individual end-user, DMI has little direct impact on your system. It does not improve performance in any way - it simply provides a standard suite of information about what’s inside the machine. Such information has little value for end-users, but may be handy when troubleshooting or upgrading a system. As a consequence, you will probably encounter DMI-enabled systems, but it is unlikely that you would "upgrade" a system to support DMI. However, standards such as DMI may eventually make "remote troubleshooting" services feasible for end-user systems.

One of the most common activities of the computer is "input/output" (or I/O) - that is, moving data into the system from a device (such as a drive controller), or putting data out to a device (like writing image data to a video adapter). Ordinarily, most I/O operations are handled through the CPU. This is perfectly normal, and modern CPUs are quite adept at managing I/O operations. The problem with CPU-based I/O is processing overhead. Every time an I/O process is handled, the CPU must stop its other, usually more important, tasks such as calculating or logical comparison, and so on. This slows down the computer’s overall processing performance - especially for calculation-intensive tasks.

If I/O processes could be handled "outside" of the CPU, the CPU could then focus on its more important tasks. This is hardly a new idea - direct memory access (or DMA) is the traditional means of channeling data without direct intervention by the CPU. However, DMA is an old and relatively slow technology which is really only useful for "low-bandwidth" data such as handling floppy drive or sound card data. For more complex systems (network servers for example), DMA is totally inadequate. Designers have developed an improved means of "off-loading" I/O operations with the introduction of "Intelligent I/O", or I²O.

But there’s another, even more compelling advantage to I²O - device and OS independence. We’ve all experienced driver problems for devices such as sound cards. For example, a Sound Blaster card uses different drivers for DOS, Windows 3.1x, Windows 95, Windows NT, OS/2, and so on. A Sound Blaster 16 card uses an entirely different suite of drivers. A Gravis sound card uses its own suite of drivers, and on it goes. Upgrading the device or operating system demands the installation of a new driver. Of course, drivers must kept up to date. This often places a great burden on device manufacturers, and continues to present a daunting problem for technicians. I²O offers BOTH device and operating system independence. Ideally, any sound card would use a single I²O driver which would work on any sound card from any I²O device manufacturer under any popular OS. Other I/O devices like modems, drive controllers, and so on would have their own "universal" cross-platform I²O driver.

In actual practice, I²O defines a standard architecture for "intelligent I/O" - an approach to I/O in which low-level interrupts are off-loaded from the CPU to I/O sub-processors (or IOPs) designed specifically to handle I/O processing. There is support for message-passing between multiple independent I/O processors, so the I²O architecture relieves the host of interrupt-intensive I/O tasks, greatly improving I/O performance in high-bandwidth applications such as networked video, "groupware", and client/server processing. I²O also provides support for single processor, multiprocessor and clustered systems.

The I²O specification also defines a "universal driver" approach for creating drivers that are portable across multiple operating systems and host PC platforms. With the proliferation of network operating systems (NOSs) - most notably NetWare 4, Windows NT Server, and UnixWare - the number of drivers that must be written, tested, integrated and supported has escalated (one for every unique combination of OS and device). Using the universal driver approach, I²O significantly decreases the number of drivers required. OS vendors write a single I²O-ready driver for each class of device (such as disk adapter) known as the OS Services Module (or OSM) and device manufacturers write a single I²O-ready driver for each device known as the Hardware Device Module (or HDM), which will work for any OS that supports I²O. This "two driver" model ensures that the OS does not have to be aware of EVERY device - only classes of devices, and each particular device will offer its own I²O driver which will interface to the OS’s I²O "device class driver".

Though I²O was developed by the I²O SIG in 1996, the actual implementation of I²O on desktop systems has been slow - largely because the I²O API needed for operating system support has not yet appeared for Windows 95 or Windows NT 4.0 (though it may appear in Windows 98 or Windows NT 5.0), and I²O-compliant devices are slow in appearing. Also, while chipsets are now available to support I²O, few desktop-class motherboards are incorporating the I/O sub-processors and PCI bridge needed to bring intelligent I/O to a PCI bus. It is possible to provide the I/O sub-processor(s) on a PCI expansion card (making it possible to add I²O support by adding the expansion card), but PCI slots are often too scarce for this tactic. Finally, few existing devices in the field actually support I²O at this time (the drivers are also limited). The I²O SIG expects general implementation of I²O by mid-1998.

One of the problems with power conservation has traditionally been "connectivity" - the PC cannot respond to the outside world while in a power-saving mode, and any network or dial-up connection already in service is usually severed. Another problem has often been that power recovery after being in a power-saving state is often a slow and convoluted process. Instant ON (a part of the APM and broad ACPI standards) resolves these issues by allowing fast recovery of the system when needed, and support for "remote waking" by external events such as incoming faxes or scheduled events such as backups or defragmenting the hard drive. This improved functionality allows you to keep the PC turned on at all times and be responsive to real-world events, yet provide excellent power conservation. Instant ON provides three key features:

• Schedule automated tasks - With Instant ON, you no longer need to be present for your PC to be productive. Programs can be run whether you are at the machine or not (and whether the machine is in use or not). Schedule disk maintenance, phone calls, and other routine tasks whenever they are most convenient. Leave your Windows 95 system powered up at all times, and the Instant ON scheduler will run the tasks you’ve specified. You can set up applications to run at particular times or on particular days. You can run programs repeatedly (i.e. once each week on Mondays or once a month on the first of the month). You can schedule programs to run several times a day if needed. They can also be scheduled to run after another application has finished a scheduled task. Instant ON also switches your PC to low-power mode to save energy and wear. If the machine is in low power, Instant ON powers it up in time to run a scheduled task.
• Unattended operation - Automating tasks also makes it possible for a computer to run in an unattended mode. For instance, you do not need to be present for your fax/modem software to receive an incoming fax, so it can run without you. The disk utilities supplied with the Microsoft Plus Pack are also designed to run using settings determined in advance. The program should also be able to stop without requiring confirmation or other input from you.

NOTE: Applications that are interactive and assume the user is present when they are running should not be run unattended. If the program pops up dialog boxes, asks for confirmation, or needs your input while it runs, do not schedule it to run when no one is at the computer.

• Energy efficient yet available - With Instant ON, you never need to turn off the PC, so you don’t have to wait for it to boot. Instant ON allows a power-managed PC to enter a low-power state when application and user activity cease, or when you choose to switch the PC to its low-power mode from the Instant ON scheduler. The system comes out of low-power mode when a scheduled task is to be run, or when activity resumes (such as when the mouse is moved). The low-power state provides energy savings while allowing the system to return immediately to full power whenever necessary.

Instant ON is actually a software application developed by Intel to enhance PCs with APM or ACPI power conservation schemes in place. To use Instant ON, you’ll need the Instant ON applet (available from www.intel.com), a PC platform that supports APM or ACPI power management, and power-managed devices (such as a modem).

One of the persistent problems for technicians is the issue of "connectivity" - connecting one device to another. This is most pronounced when connecting peripheral devices like printers. Cabling is always a hassle - especially for mobile PCs and stationary printers. Another connectivity issue occurs with PC-to-PC file exchanges using tools like Windows 95’s Direct Connect feature. Rather than deal with the physical connection of systems or serial devices, the Infrared Data Association (the IrDA) has developed the IrDA port for serial communication over an OPTICAL (infrared) link. Just a few applications for IrDA ports include:

• Printing from a desktop or notebook PC without cables.
• Synchronizing files between PCs, or between hand-held PCs and desktop systems.
• Sending faxes/e-mail from a notebook PC through an IrDA-equipped telephone.
• Banking using a mobile PC and IrDA-equipped ATM.
• Accessing a network with a mobile PC using an IrDA-equipped node.

In September 1993, IrDA outlined the basis for the IrDA SIR Data Link Standards. In June 1994, IrDA published the IrDA standards which includes Serial Infrared (SIR) Link specification, Link Access Protocol (IrLAP) specification, and Link Management Protocol (IrLMP) specification. IrDA released extensions to SIR standard (including 4Mb/S) in October 1995. The IrDA standard specification has been expanded to include high speed extensions from 1.152 Mb/S and 4.0 Mb/S. This extension will require an add-in card to retrofit existing PCs with high speed IR, and synchronous communications controller or equivalent.

While the IR serial port offers some serious advantages to PC users, there are also some limitations to IR technology that you should keep in mind before using or upgrading to an IrDA port:

• IR working range is limited to 1m to about 3m.
• You need a direct line of site between two IR ports.
• The two IR ports must be directly facing one another (an angle of no more than 30 deg).
• IrDA drivers and software further complicate an already crowded Windows 95 platform.

IrDA ports are now being incorporated into many new mobile computers and peripherals (especially printers). If you already have IrDA-enabled devices, you just need IrDA software and drivers for Windows 95. If you want to upgrade existing desktop systems, mobile systems, or peripherals, you can purchase and install IrDA adapters for existing serial ports (including the software and drivers needed to operate the IrDA adapters).

Battery operated equipment - namely mobile PCs - presents some perplexing challenges to end-users. In many cases, it is difficult (if not impossible) to accurately determine how much of a charge remains on the battery, or how long it will take for the battery to charge, or how the insertion or removal of devices (i.e. PC Cards) will effect the remaining battery life. Intel has addressed this problem with the introduction of the System Management Bus (or SMBus) which is designed to operate in conjunction with "smart batteries" (Fig. 36-3).

SMBus support starts in the PC chipset, and is most often included with current mobile PC chipsets (such as Intel’s 430MX). The "smart battery" can be connected directly to the SMBus host over a two wire serial interface. SMBus BIOS provides the low-level BIOS support needed to operate the SMBus host, and an SMBus API provides the high-level operating system support and dialog boxes used to configure and operate the SMBus.

The key to a successful SMBus is the "smart battery" itself. In addition to the electrochemical components of a traditional battery, the "smart battery" incorporates active circuitry which adds a level of intelligence to the battery. The battery can then pass messages about its status, and respond to queries from the system. The smart battery’s software API was designed to meet stringent requirements for data from the battery. The data that a smart battery must report falls into several general categories:

• Alarms - the battery is about to run out.
• Control/Status/Error - to control the battery’s operating mode.
• Predictive functions - indicating how long will the battery will supply power at a given rate.
• Measured data - indicting how much current the battery is supplying.
• Battery state of charge - the fuel gauge information.
• Charging information - indicating how to properly charge the battery.
• Battery characteristics - outlining the design capacity and cell chemistry of the battery.
• Manufacturing Data - providing the manufacturer’s name and serial number.

Since the SMBus was designed primarily for mobile PCs, you will probably encounter SMBus and smart battery configurations, but you cannot add SMBus support to an existing system. The most important impact you’ll have on smart battery operations is the proper configuration of Smart Battery software.

Connecting devices to a computer continues to be a problem for technicians. The PC must be powered down (and usually opened) before new devices or peripherals can be added or replaced. The system must then be rebooted in order to recognize the new device, load the drivers, and prepare the device for service. Designers have long sought to develop an interface which is simple, robust, and provides "hot swappable" connectivity so that devices can be attached and removed with power applied. This is a vision which not only requires a fundamental shift in the way devices are designed, but also demands changes to the operating system for "as needed" device recognition and handling. The Universal Serial Bus (or USB) is the first step toward realizing these goals for low-to-medium bandwidth peripheral devices like monitors, printers, digital speakers, modems, graphics tablets, scanners, digital cameras, joysticks, and so on. You can find the "first wave" of USB products highlighted at: http://developer.intel.com/design/usb/frstwave.htm.

USB has two data rates; a 12Mbps rate for devices requiring increased bandwidth, and a 1.5Mbps rate for lower-speed devices like joysticks and game pads. USB uses a "tiered star topology", which means that some USB devices - called USB "hubs" - can serve as connection ports for other USB peripherals. Only one device needs to be plugged into the PC. Other devices can then be plugged into the hub. USB hubs may be embedded in such key devices as monitors, printers and keyboards. Stand-alone hubs can also be made available. Hubs feature an upstream connection (pointed toward the PC) as well as multiple downstream ports to allow the connection of additional peripheral devices. Up to 127 USB devices can be connected together in this way. Industry pundits often refer to this as "plug-and-play outside of the box".

USB host controllers (which are available as part of several Intel PCI chip sets) manage and control the driver software and data flow required by each peripheral connected to the bus. Users don’t need to take any specific configuration action because all the configuration steps happen automatically - the USB host controller even allocates electrical power to the USB devices. USB hubs and host controllers can detect attachments and detachments of peripherals occurring downstream and supply appropriate levels of power to downstream devices as needed. Figure 36-4 illustrates a typical USB connector and pinout.

Most new systems are equipped with one or two USB ports (usually located in the area of COM or LPT ports). In this case, it is simply a matter of attaching a USB hub (such as a USB keyboard), and then attaching USB devices to the hub. For systems without USB, you’ll need a motherboard upgrade which contains a USB-complaint chipset and port(s). Most current ATX and NLX motherboards will sport a USB port. Once the new motherboard is in place, USB devices can be attached.

That concludes the material for Chapter 36. Be sure to review the glossary and chapter questions on the accompanying CD. If you have access to the Internet, take a look at some of the various resources listed below:

ACPI: http://www.teleport.com/~acpi/

APM: http://www.intel.com/IAL/powermgm/

AGP: http://www.agpforum.org/

ATX: http://www.teleport.com/~atx

Device Bay: http://www.device-bay.org

DMI: http://www.dmtf.org/

I²O: http://www.i2osig.org/

IrDA: http://www.irda.org/

Smart Battery and SMBus: http://www.sbs-forum.org/

Instant ON Scheduler: http://developer.intel.com/ial/inston/install.htm

USB: http://www.usb.org/