The Official Reference for Designing PCs and Peripherals for the Microsoft(R) Windows(R) Family of Operating Systems

The Official Reference for Designing PCs and Peripherals for the Microsoft® Windows® Family of Operating Systems

Microsoft Corporation

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft Corporation.

Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties of merchantability, fitness for a particular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages; the above limitation may not apply to you.

ActiveMovie, ActiveVRML, ActiveX, BackOffice, BallPoint, Direct3D, DirectDraw, DirectInput, DirectMIDI, DirectPlay, DirectSound, DirectX, Microsoft, Microsoft Press and Design, MS-DOS, NetMeeting Win32, Windows, Windows NT, and the Windows logo are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Etherworks is a trademark of Digital Equipment Corporation. NetWare is the registered trademark of Novell, Inc. Pentium is a registered trademark and EtherExpress and TokenExpress are trademarks of Intel Corporation. Personal System/2 and PS/2 are registered trademarks and PowerPC and PowerPC Architecture are trademarks of International Business Machines Corporation. TrueType is a registered trademark of Apple Computers, Inc. Other product and company names herein may be the trademarks of their respective owners.

© 1996 Microsoft Corporation. All rights reserved.

PC 97 Editorial Team: Annie Pearson, David Williams.

PC 97 Production and Editorial Assistants: Catherine Horne, Jan Wright, Ilya Balyeat.

Contributing Writers: Joe Decuir, Mike Flora, Keith Laepple, Steve Loewen, Annie Pearson, Steve Timm, Mark Williams.

Technical Contributors: George Allen, David Alles, Matthew Anderson, Felix Gti Andrew, Frank Artale, T.K. Backman, Alistair Banks, Peter Biddle, Eric Bidstrup, Kristi Bolen, Jay Borseth, Mike Borsheim, Billy Brackenridge, Kyle Brandon, Kecia Bruce, Marshall Brumer, Seth Catlin, Jim Cobb, Ken Cooper, Trudy Culbreth, Alireza Dabagh, Joseph Dadzie, Rick Dewitt, Brian Emanuels, Charles Fitzgerald, David Flenniken, Forrest Foltz, Pat Fox, Bob Fries, Lynn Fulks, John Nels Fuller, Steve Gabriel, Mike Glass, Ty Graham, Laurie Griffiths, Robert Gross, Wassef Haroun, Bob Heddle, Jay Hendricks, Scott Herrboldt, Jameel Hyder, Bruce E. Johnson, Walt Jones, Joseph Joy, Jonathan Kagle, John Kalkman, Barry Kelman, Mark Kenworthy, Servan Keondjian, Jawad Khaki, David Kline, Doug Klopfenstein, Larry Landsverk, Todd Laney, David Lao, On Lee, Tom Lennon, Jim Livingston, Greg Lowney, Richard Machin, Jon Marbry, Tom McGuire, Rob McKaughan, Lonny McMichael, Ted Miller, Arvind Murching, Andrew Nicholson, Pekka Nikkonen, Charles Park, Bill Parry, Ray Pedrizetti, Dan Perry, Kevin Phaup, Shaun Pierce, Bill Powell, Ron Radko, Ken Reneris, Aaron Reynolds, Bob Rinne, Husni Roukbi, George Roussos, Pierre-Yves Santerre, Chuck Scott, Mark Sestak, Nathan Sherman, Keith Shetterly, Glen Slick, Doug Spencer, Matt Squires, Ed Stubbs, Glenn Thompson, Andre Vachon, Mike Van Flandern, Brad Vavra, Bill Veghte, Channing Verbeck, Bryan Willman, Steve Wright, Craig Zhou.


Chapter 1 PC 97 Design Issues

"PC 97" represents the collection of PC system definitions and bus and device design requirements that make up the next generation of guidelines for the "Designed for Microsoft Windows" logo.

This chapter introduces the PC 97 design issues for computer systems that run the Microsoft Windows family of operating systems for x86-based PCs and that run Windows NT on the RISC-based processor platform.

For more information about design issues related to the OnNow design initiative and Win32 Driver Model, see the "OnNow and WDM for PC 97" chapter.

Important The system requirements defined in PC 97 Hardware Design Guide provide guidelines for designing PC systems that best run Windows 95 and Windows NT. These design requirements are not related to the basic system requirements for running a Windows operating system. For information about the basic system requirements for running Windows 95 and Windows NT, see:

http://www.microsoft.com/windows/mix/


Evolving the PC Platform

Every member of the PC industry has an important business goal that involves growing the PC market among business and home users. An important key to growing any part of the PC hardware market is to increase the ease of use for PCs in general and to provide support for new kinds of hardware in particular:

  • Business customers need improved ease-of-use capabilities for hardware, both to increase end-user productivity and to lower support costs, resulting in reduced total cost of ownership.
  • Home users need easier-to-use hardware to overcome barriers to learning and using unfamiliar technology.
  • All users need hardware and operating-system support for new technologies that will lower costs, improve usability, and improve performance for communications, applications, and media titles.

The endeavor to make PC hardware easier to use can only be accomplished as an industry partnership among hardware vendors, PC manufacturers, and Microsoft to design hardware, operating systems, and software that work together effectively. One of the most exemplary efforts for this endeavor in the recent past has been the Plug and Play initiative that the industry has embraced.

To continue evolving both the usability and new capabilities for PC hardware, the industry must continue to work on evolving the PC platform in key ways:

  • To enhance the usability and supportability of existing and new hardware devices in ways that lower everyone's support costs.
  • To broaden consumer PC capabilities so that the PC becomes a center for entertainment, communications, and home productivity.

Microsoft is dedicated to working in strategic industry relationships that deepen and strengthen support for evolving the PC platform. To this end, Microsoft is involved in these efforts:

  • Working with industry groups to define standards for new technologies.
  • Designing operating-system support for new bus and device classes to ensure new technologies can reach a broad market quickly.
  • Enhancing the Windows operating systems to make it easy for both hardware and software developers to exploit operating system capabilities.
  • Offering the "Designed for Microsoft Windows" logo and testing program to enable users to identify hardware and software designed or take advantage of the Windows operating systems.

The intent of the PC 97 Hardware Design Guidelines and the "Designed for Microsoft Windows" program is to make PCs, hardware components, and software easier to use. The system design requirements defined in this guide support a synergy among PC hardware, Microsoft Windows operating systems, and Windows-based software. The new PC 97 requirements for systems and components are based on the following high-level goals:

  • Support for Plug and Play compatibility and power management for configuring and managing all system components, including new requirements under the OnNow design initiative.
  • 32-bit device drivers and installation procedures for both Windows 95 and Windows NT written as defined in the Windows 95 DDK or the Windows NT DDK.
  • Compliance with standards for system platform, buses, and devices:
  • Buses and devices meet industry specifications for each bus type.
  • Devices meet industry standards and specifications for each device class.
  • System and devices meet minimal performance standards.
  • System and devices meet guidelines for ease of use and industrial design.


Logo Program at Microsoft for Hardware

The "Designed for Microsoft Windows" logo on PC hardware provides end users with the assurance that this hardware will work well with Windows and that it takes advantage of features built in to the operating system. Products that receive this logo go through a rigorous series of tests administered by the Windows Hardware Quality Labs (WHQL) to determine that the hardware meets all "Designed for Microsoft Windows" criteria.

The first "Designed for Microsoft Windows 95" logo program was based on requirements defined specifically for Windows 95. Under the requirements for the first logo program, part of the logo testing requirements have been that a product be tested under Windows NT, with the requirement being that the product must run successfully on both Windows 95 and Windows NT unless prevented by architectural differences between the two operating systems. This guide defines the specific differences for drivers or other support under the two operating systems.

The collection of categories for PC 97 system types are the following:

  • Basic PC 97: Defines a standard PC (both desktop and mobile) that sets a baseline of features and performance for users in all categories. The Basic PC 97 system is designed to best support typical Windows-based applications running under either Windows 95 or Windows NT Workstation. However, these requirements represent much more than the minimum system requirements for the operating systems, which are much lower in order to support a large base of older, less capable hardware.
  • Workstation PC 97: Defines enhanced components for a PC system designed to support the more complex requirements of Win32®-based applications that have strenuous graphics or computational demands. A Workstation PC 97 system can run either Windows 95 or Windows NT Workstation, but its design is optimized to support Windows NT Workstation when used for complex applications such as CAD or engineering computing, software development, and content authoring for the Internet or applications.
  • Entertainment PC 97: Defines enhanced components for a PC system designed as an interactive multimedia system optimized for games, education, personal communications, Internet activities, and video playback. Key features that differentiate Entertainment PC 97 from other system types include support for advanced game playing 3-D graphics and audio, high-performance graphics and video including full motion MPEG-2 video, high-fidelity audio, and connections to consumer-electronics devices such as home stereos, telephones, VCRs, camcorders, digital satellite systems, and so on.

The PC 97 requirements for each system type are defined in Part 2 of this guide. In addition, there are additional specific logo criteria for each bus and device class, as defined in Part 3, "Bus Design for PC 97," and Part 4, "Device Design Guidelines," in this guide.

Notice that mobile PCs are not defined as a separate system category, as mobile PC designs could be implemented under each PC 97 system type. The "Basic PC 97" chapter presents a summary list of specific design issues for mobile PCs and docking stations. Also, PC 97 Hardware Design Guidelines do not apply for so-called personal digital assistants (PDAs) or other sub-PC form factor designs.

Microsoft will continue to have a single logo for all categories of computers defined for PC 97. However, for systems submitted under the Workstation and Entertainment PC categories, in 1997 Microsoft will be announcing and offering additional marketing programs for those specific categories.


Designing PCs for Windows 95 and Windows NT

The new guidelines presented in PC 97 Hardware Design Guide define PC system types and component requirements for the Microsoft Windows family of operating systems. This means that, for the first time, the "Designed for Microsoft Windows" program requirements are defined in one place for two operating systems:

  • Microsoft Windows 95. Windows 95 is an operating system for platforms that use Intel and equivalent microprocessors (referred to as "x86-based systems" in this guide). Windows 95 is the successor to MS-DOS®, Windows version 3.1, and Windows for Workgroups version 3.x. Windows 95 includes built-in networking capabilities and broad support for legacy hardware and software, plus support for new hardware and new APIs.
  • Microsoft Windows NT Workstation and Windows NT Server. Windows NT is a preemptive, multitasking operating system that includes security and networking services as fundamental components of the base operating system. Windows NT runs on both complex instruction set computing (CISC) and reduced instruction set computing (RISC) processors. Windows NT also supports high-performance computing by providing kernel support for computers that have symmetric multiprocessor configurations.

In 1996, Windows 95 and Windows NT 4.0 share such technologies as the Win32 API, OLE, networking, and user interface, so it is possible to run applications based on a common API set and a common object technology. Both products contain the essential infrastructure for desktop management by using a system registry that is accessible remotely using Win32 APIs.

In the future, these operating systems will share even more capabilities, including the Win32 Driver Model (WDM), the new Advanced Configuration and Power Interface (ACPI), and Plug and Play capabilities, as described in the "OnNow and WDM for PC 97" chapter. Other shared capabilities will include Microsoft DirectX™ APIs, ActiveX™ APIs, and distributed Component Object Model protocol (formerly referred to as "network OLE"). Because of differences in product development cycles, new technologies might appear on one product before the other, but these differences will be temporary.

All support for new technologies such as USB input devices and IEEE 1394 digital video devices will use WDM. To take advantage of new support in both operating systems, the hardware manufacturer can use the built-in drivers or create only a minidriver to exploit specific features in the hardware.

Although more code will be shared on both platforms over time, there will continue to be two complementary desktop operating system products to meet the diverse needs of business and end users.


Designing with New Bus and Device Support

New cross-platform support for PC 97 includes the following:

  • Support for ACPI and the OnNow initiative for power management and Plug and Play support, as described in the "OnNow and WDM for PC 97" chapter.
  • Support for the new Win32 Driver Model (WDM), with binary compatibility for new drivers across both operating-system platforms, as described in the "OnNow and WDM for PC 97" chapter.
  • Support for new universal serial bus (USB) and IEEE 1394 (sometimes called "firewire").

    USB is a serial protocol that runs at 1–12 megabits per second, making it an appropriate bus for input devices, modems, digital audio, and digital image input devices.

    IEEE 1394 is a serial protocol that runs at speeds ranging from 100 – 400 megabits per second, depending upon the implementation. Devices that are prime candidates for IEEE 1394 include digital camcorders and VCRs, digital audio amplifiers, and video teleconferencing.

    All new buses supported for PC 97 will support Plug and Play functionality and will include WDM system drivers for both Windows 95 and Windows NT.

  • Support in both operating systems for new hardware, including:
    • DVD.
    • Digital image input devices.
    • Network communications devices such as ISDN and cable modems.
    • Connectivity to consumer-electronic devices such as the home stereo, digital VCR and camcorder, digital satellite, and cable TV.
  • Support for new Microsoft APIs, including:
    • DirectDraw™ and Direct3D™ APIs for 2-D and 3-D graphics acceleration.
    • DirectSound™ for sound acceleration.
    • ActiveMovie™ and ActiveVRML™ for full-motion video, MPEG-1 acceleration, and other multimedia streaming for both PC-based and Internet applications.
    • Telephony functions for conferencing, voice mail, and fax.
    • Support for multiple monitors, large monitors, and higher quality video display.


SIPC and Designing for Ease of Use

The installed base of personal computers in U.S. homes is still around 30 percent, which is far lower than for any other consumer-electronics device such as TV, VCR, or telephone. A chief barrier to more widespread adoption of the PC in the home is a common feeling among consumers that PCs are difficult to learn, use, and maintain. In addition, many people worry about the perceived short lifetime of a computer and its essential obsolescence within a few years.

To more deeply penetrate the consumer market, the combined elements of the PC design must make it possible for novice users to easily carry out key tasks without experience, including:

  • Playing a game or watching a video stream such as a movie or DVD title.
  • Writing e-mail or writing a letter for printing.
  • Browsing the Internet or listening to voice-mail messages.
  • Hooking up another device to the PC.

Research with end users has revealed these areas that call for design attention to broaden the consumer PC market:

  • Industrial design for the home, with easy setup and extensibility.

    Form-factor issues for such design include size, color, and convenience of connections, switches, and so on. Designing a PC that contains no user-serviceable parts has strong appeal for consumer markets.

    The USB and IEEE 1394 external bus architectures will play a key role in many of the ease-of-use scenarios, such as the ability to hot plug any device without rebooting the PC.

  • Instantly accessible and quiet.

    Key elements of the OnNow initiative serve this design area. The user should be able to expect the PC to perform as instantly as other electronic devices such as VCR or TV, while also expecting the PC to not introduce extra noise into the home environment.

  • Sound, video, and other media performance with better quality and better user control than available from other entertainment components.

    This means, for example, supporting video display on large monitors with better quality video definition than provided by the TV, or providing PC-controlled audio output at a quality equivalent to home stereos.

  • Integration of many separate consumer-electronic devices into one unit.

    The PC should be able to control and integrate operation of any standalone device in the home that produces or manipulates information, including the TV, stereo, VCR, CD player, DVD, laser disc, digital satellite services, game console, and so on.

The Simply Interactive Personal Computer (SIPC) initiative at Microsoft is a vision and framework of technologies devised to advance the PC platform by identifying core improvements required to dramatically enhance the level of usability and functionality of both Windows 95 and Windows NT family of operating systems, and PC hardware.

SIPC is not a PC design and the PC 97 guidelines should not be seen as definitions of an SIPC design. The results of the SIPC initiative — both hardware and software — will apply to all categories of systems, including entertainment PCs, mobile PCs, business PCs, workstations, and servers. There is no particular "SIPC" system design, rather just SIPC "focused" hardware technologies, system features, and software designs.

The SIPC initiative can be expressed as a series of goals with specific deliverables associated with them that could apply to any PC hardware platform, form factor, or category of PC platform. SIPC goals also apply to both operating systems, with a high priority at Microsoft to bring the same feature support and functionality to both Windows NT and Window 95.

A good example of a SIPC technology would be OnNow, designed to bring a scaleable set of power management and control features to both PC hardware and the operating system, regardless of the form factor, market category, or platform.

The following diagram represents the technologies that SIPC covers. How they are applied to a market category or form factor is based on the market demands for the product line.

SIPC technologies and PC market categories
(Drawing is representational only and is not to scale.)

For PC 97 and SIPC, the term "sealed case PC" is intended to drive the ease of use concept to a new level for the PC platform. Today we have sealed case PCs in the form of mobile and laptop computers. These systems are self contained and provide features to make it exceedingly easy to add and remove components, including memory upgrades, without the end user having to open the PC and partially disassemble boards and cables to add a device to the system.

This concept must be applied in a much broader way to allow the same ease of use for any system form factor. These ideas — that the PC contains "no user serviceable parts" inside, that PCs can be upgraded easily by anyone, and that a sealed-case PC is expandable — are not mutually exclusive, unattainable goals.

The sealed-case PC fits into the SIPC framework of technologies including USB, IEEE 1394, and modular RAM and CPU upgrade. However, Microsoft does not expect that all SIPC designs will be actually "sealed," even when they do support these expansion methods.


Plug and Play and Designing for Extensibility

A key goal for PC 97 is to provide expansion capabilities "outside the box." Use of USB and IEEE 1394 are emphasized for connecting devices in PC 97 systems, to ensure that the expansion capabilities are physically accessible to the user and to ensure that the user can take advantage of automatic device configuration and hot plugging capabilities.

A second goal is to manage resources for PC devices to ensure that it is always possible to configure resources for all devices. This means, for example, that any device which uses interrupts always has an interrupt available so that the device can be enabled. The key requirement for meeting this goal is that each bus and device following the relevant Plug and Play specifications.

For 1997, the challenge for Plug and Play is to simplify and unify the underlying mechanisms and deliver a common Plug and Play model for both Windows 95 and Windows NT. The Win32 Driver Model and the Advanced Configuration and Power Interface form the foundation for this common model.

Although VxD-based Plug and Play-compatible drivers will continue to be supported on Windows 95, WDM ensures that future Plug and Play investment is leveraged for both operating systems. In addition to enabling operating system-directed power management, ACPI provides device configuration and generic system event mechanisms for Plug and Play and also provides an operating system-independent interface for configuration control. ACPI leverages the Plug and Play BIOS data structures while providing a processor architecture-independent implementation that is compatible with both Windows 95 and Windows NT.

The previous "Designed for Microsoft Windows 95" logo requirements emphasized Plug and Play as the central focus. For the important buses used in a PC 97 system, the key Plug and Play design work is in place, so that very little new Plug and Play work is designated for PC 97, beyond modifications required on the system board for migration to the ACPI specification.

For PC 97, all devices provided in the system must comply with the current Plug and Play specifications. The operating system must be able to reconfigure the system without requiring the user to restart the PC (with a few exceptions outlined in the detailed requirements in this guide).

Plug and Play for extensibility. A fundamental element of Plug and Play is that each device has a unique identifier. A Plug and Play device identifier is constructed from the logical device identifier structures documented in the specifications for a particular bus, as defined in Part 3 of this guide. The following information is required to create a device identifier for each device on a particular bus:

  • USB: An identifier that follows the current guidelines defined in the Universal Serial Bus Specification and related device class specification.
  • IEEE 1394: A global unique 64-bit identifier as defined in the IEEE 1212 Control and Status Register Format Specification.
  • PCI: A value consisting of the Vendor Identifier, Device Identifier, Class Code, Revision ID, Header Type, Subsystem ID, and Subsystem Vendor ID defined in the Configuration Space header for each PCI device, as defined in the PCI v. 2.1 specification.
  • PCMCIA: An identifier created from tuples as documented in the "PC Card" chapter in Part 3 of this guide.
  • ISA: A 32-bit EISA-type identifier for each Plug and Play ISA device. This identifier consists of a leading zero followed by three compressed ASCII characters and a unique 16-bit identifier for each logical device design. To register a new device ID, please send e-mail to pnpid@microsoft.com.
  • Serial (COM) device: A string of up to 256 characters with five mandatory fields and ten optional fields, as defined in Section 3 of the Plug and Play External COM Device Specification, v. 1.0.
  • Parallel (LPT) device: A string of up to 20 characters concatenated from MFG, CMD, MDL, CLS, DES, and CID fields, as defined in the Plug and Play Parallel Port Devices Specification, v. 1.0b.

Requirements related to Plug and Play for option ROMs are defined in the "Basic PC 97" chapter in Part 2 of this guide; option ROM requirements for specific devices are defined in the "SCSI" and "ATA and ATAPI" chapters in Part 3, and also in the "Graphics Adapters" chapter in Part 4 of this guide.

Bus choices for extensibility. When choosing expansion bus support for the PC system and determining which devices should use a particular bus, the PC system designer should consider the bandwidth requirements for each particular device, in addition to selecting a bus based on ease-of-use considerations.

For USB, for example, multiple devices will be using the bus. Therefore, as a general guideline, any device that consumes 30 percent or more of the available bandwidth should be implemented using a higher-speed bus such as IEEE 1394. An example for such a choice would be a digital video device such as a digital VCR or camcorder.

A PC 97 system can provide an ISA bus to allow end users to "recycle" their old ISA devices. A PC 97 system that provides ISA support must fully implement Plug and Play boot support, IRQ sharing for ISA (if need to meet resource requirements), and other mechanisms to ensure that an ISA card added to the system can be configured and enabled. Any ISA devices provided with the system must be fully Plug and Play compatible.


Designing for x86-based and RISC-based PCs

Windows NT and Windows 95 are designed to run on platforms that use Intel and equivalent microprocessors, referred to as "x86-based systems" in this guide. These operating systems can run on computers running with Intel 80486-class, Pentium-class, or Pentium Pro-class processors, or equivalent microprocessors that implement the complete 486 instruction set.

Windows NT can also run on RISC-based computers, which includes computers with MIPS R4000 or Digital Alpha 21064 (EV4) or higher processors, or computers that use the IBM PowerPC Architecture.

  • When Windows NT is running on an x86-based processor, a virtual-86 processor mode allows direct execution of most instructions in MS-DOS – based applications. A few instructions, such as I/O instructions, must be emulated to virtualize the hardware.
  • When Windows NT is running on a RISC-based processor, hardware support for executing x86 instructions is not available, so Windows NT emulates all x86 instructions and provides a virtual hardware environment using the Virtual Device Manager (VDM). The Windows NT VDM also supports ROM BIOS interrupt services, MS-DOS Interrupt 21 services, and virtual hardware for devices using virtual device drivers (VDDs).

This guide provides complete hardware design guidelines for the x86-based computer, whether it is running Windows 95 or Windows NT, plus requirements for RISC-based PCs that run Windows NT. There is no future plan to enable Windows 95 to run on RISC-based PCs.

Advanced RISC computing (ARC) refers to a RISC-based computer architecture standard associated with the ACE consortium. Windows NT runs on top of ARC-compliant PCs, including both RISC- and CISC-based platforms that supply the following components to the operating-system loader:

  • For ACE-compliant platforms, such as most MIPS systems, the system firmware supports bootstrap loading and execution as an "abstracted" set of ARC routines and ARC devices.
  • For x86-based platforms, a Windows NT hardware recognizer (Ntdetect) finds devices necessary to bootstrap the system by querying the ROM BIOS and then builds a hardware database that emulates the RISC-based ARC firmware.
  • For both kinds of platforms, a hardware abstraction layer (HAL) interfaces between the hardware and the system. Device drivers for certain types of devices create an alias between the names of their device objects and the corresponding ARC device name by calling the appropriate API.

In Windows NT, for some devices there are no differences in the requirements for supporting any microprocessor platform. For example, a network adapter driver calls DMA-related functions of the NDIS interface library for DMA operations between the host and the network adapter. These functions support maximized portability, so the driver can run on both x86-based and RISC-based architectures.

However, some differences in microprocessor platform requirements must be addressed in the Windows NT device driver. For example:

  • Phase 1 of system startup for Windows NT is microprocessor platform-specific. On x86-based PCs, the hardware boot ROM loads a boot sector, which loads the NTLDR.

    For most RISC-based platforms, the firmware loads necessary ARC drivers, acquires hardware configuration data, and loads the OSLOADER.

  • Phase 2 of Windows NT system startup sets up memory, captures hardware configuration data, constructs a description of the hardware in memory, and puts a pointer to this description into the loader block.

    On x86-based PCs, a hardware recognizer called Ntdetect queries the ROMs, probes the hardware, and collects as much information as possible about the I/O buses and peripheral devices in the PC system.

    On RISC-based PCs, the ARC Query Config functions are called to accomplish the same thing.

  • On x86-based PCs, there is no difference between a Win32 address and a DMA address as programmed by the MS-DOS – based application to the DMA chip.

    On RISC-based PCs, you must add the offset from VDM 0 to DOS 0:0 to convert a DMA address to a Win32 address.

  • On x86-based PCs running Windows NT, there are two kinds of video miniport drivers: VGA-compatible miniports and miniports that rely on having the system-supplied VGA miniport driver or another VGA-compatible SVGA miniport driver loaded concurrently.

    Miniport drivers on RISC-based platforms rely on the system-supplied VGA support, if it is necessary. For all RISC-based platforms running Windows NT, video miniport drivers need not supply any special support for full-screen MS-DOS – based applications. Instead, video miniport drivers must be set up to configure themselves in the registry with VgaCompatible=false.


References for PC 97 Design Issues

This section lists some of the publications, services, and tools available to help build hardware optimized to work with Windows operating systems.

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Microsoft Device Driver Kits (DDKs) for Windows operating systems

Microsoft Developer Network (MSDN) Professional membership

Advanced Configuration and Power Interface (ACPI) specification

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

Power management specifications for device and bus classes

http://www.microsoft.com/hwdev/onnow.htm

Hardware compatibility tests

http://www.microsoft.com/hwtest/


Chapter 2 OnNow and WDM for PC 97

This chapter introduces the PC 97 design issues related to the OnNow design initiative and Win32 Driver Model (WDM).


OnNow Design Initiative and PC Evolution

For 1997 and beyond, platform advancements will focus in these areas:

  • Ease of use. The combination of hardware, software, and operating system interfaces still make it difficult for a novice to walk up and effectively use a PC for the first time.
  • Serviceability. This relates to the availability and simplicity of the PC for performing tasks that the customer may encounter in everyday life.
  • Extensibility and accessibility. PC systems must be capable of easily incorporating new technologies, rather than becoming obsolete as new technologies are introduced. New capabilities must be as easy to implement in a PC system for the user as plugging in a power cord.

Although the industry has come far with Plug and Play and other recent advancements to make the PC platform easier to use, customers — and potential customers — want the PC to be even more convenient to use. To enable the PC to become a much more integral part of daily life both in the office and the home, the PC must be instantly available to answer the phone, display new e-mail, or browse the Internet, but appear to be off when not in use.

The goal of the OnNow initiative is to advance the PC platform to a high level of usability and robustness that will allow the PC to deliver these new capabilities. To meet the goals of this initiative, it is essential that all system components work together to ensure the PC operates as the user would expect.

The following describes how the OnNow PC platform is expected to work:

  • The PC is ready for use immediately when the user presses the power button.
  • The PC is perceived to be off when not in use but is still capable of responding to wakeup events. In this context, appearing off means that the PC seems to be off according to what the user hears and sees, but also that the user is confident that the PC is not consuming excess energy and that data and programs are reliably saved. Wakeup events might be triggered by a device receiving some input such as a phone ringing or a timed alarm set by software.
  • Software adjusts its behavior when the PC's power state changes. The operating system and applications work together intelligently to operate the PC in accordance with the user's current needs and expectations and to deliver effective power management. For example, applications will not inadvertently keep the PC busy when it is unnecessary and instead will proactively participate in shutting down the PC to conserve energy and reduce noise.
  • All devices connected to the PC or added by the user participate in the device power management scheme. Any new device can have its power state changed as system usage dictates.

To achieve this set of capabilities requires a comprehensive, system-wide approach that affects all aspects of the PC. New requirements for the operating system, applications, device drivers, and hardware must be incorporated into the PC system to deliver transparent power management and improved integration of components. The necessary changes are the following:

  • Enhanced core operating system functionality for power management. In the OnNow architecture, the operating system assumes the central role of coordinating power management activities at all levels and takes responsibility for defining the power state transitions for the system. It is planned for both Windows 95 and Windows NT to incorporate these changes in 1997.
  • A unified device driver model for power management and Plug and Play. This involves the creation of a device driver model that supports per-device power management and Plug and Play for both Windows and Windows NT. The Win32 Driver Model is designed to fill this need.
  • A new system interface for power management and Plug and Play. A design is required for implementing operating system-directed power management and enabling per-device power management of devices on the system board. The design defined by the Advanced Configuration and Power Interface meets this need and also provides future extensibility and improved system integration.
  • Device and bus hardware power management advances. In the same way that Plug and Play unified configuration mechanisms throughout the PC, OnNow provides a framework for defining power management interfaces and state definitions. For example, new power management specifications have been developed for PCI, USB, and IEEE 1394 buses.
  • An application architecture that integrates applications into power management. Building on the existing Plug and Play mechanisms for applications, it is necessary to further improve the flow of control and information through the application interface so that the user's environment is much more smoothly integrated with the underlying PC capabilities.


ACPI for PC 97

A key component of the OnNow design initiative is a new system board design based on the Advanced Configuration and Power Interface (ACPI) specification. ACPI defines a flexible and abstract hardware interface that enables a wide variety of PC systems to implement power and thermal management functions while still meeting the cost and feature requirements of the target market.

ACPI also provides device configuration and generic system event mechanisms for Plug and Play. ACPI therefore replaces the Plug and Play BIOS and unifies the power management interface with the Plug and Play interface. It also provides support for configurations and resource types that could not be supported before.

ACPI leverages the Plug and Play BIOS data structures while providing an implementation that is independent of the processor architecture and compatible with both Windows 95 and Windows NT.

For OnNow, ACPI enables the operating system to direct power management throughout the PC system, improving integration, increasing effectiveness, and simplifying implementation. System designers have the freedom to implement a wide range of solutions, from the very simple to the very aggressive, while still maintaining full operating system support under both Windows 95 and Windows NT.

Further, power management policies that might be too complicated to implement in hardware or a ROM BIOS can be implemented and supported in the operating system, allowing inexpensive power-managed hardware to support elaborate power management policies.

Finally, ACPI enables investment in power management as a mainstream feature of both PC system hardware and operating systems, while allowing the ongoing independent evolution of each.

This pervasive implementation of power management will enable applications to routinely implement support for these capabilities, introduce new OnNow features, and improve the effectiveness of power management in the PC. Because of the emphasis on convenience and the OnNow goals, and because of the need to enable power management in both Windows 95 and Windows NT, the PC 97 system designs are based on this important new standard.


Win32 Device Driver Architecture

Currently, support for new buses and new classes of PC peripherals poses new challenges for driver development. New buses increase the number of devices and requirements for device drivers. Increasing integration of multifunction devices further complicates driver development. At the same time, low-latency interactive applications demand tighter integration of software and hardware. For 1997, each of these factors are accounted for in the evolution of the unified Win32 Driver Model for Windows 95 and Windows NT. WDM allows a single driver source (x86 binary) to support a new bus or a new device on both Windows 95 and Windows NT.

Key goals for WDM are to simplify driver development by providing the flexibility to support new and innovative hardware while also reducing the number and complexity of drivers that must be developed. WDM must also provide a common framework for Plug and Play and device power management. WDM is a key component to enable innovative device support that is simple and convenient to use.

To achieve these goals, WDM is based on a common set of services provided by the Windows NT I/O subsystem. WDM advances consist of a set of kernel extensions to support Plug and Play, device power management, and low-latency streaming I/O. In addition to common platform services and extensions, WDM implements a modular, layered class minidriver structure. Class drivers implement functional interfaces required to support a generic bus, protocol, or device class. The generic nature of class drivers offers the opportunity for standardization of logical device command sets, protocols, and bus interfaces necessary for code reusability. WDM support for standard class interfaces reduces the number and complexity of device drivers required for both Windows 95 and Windows NT.

Minidrivers allow extension of generic class drivers to support a specific device protocol or physical programming interface. For example, a minidriver can be implemented to extend an IEEE 1394 bus class driver to support a specific host controller programming interface. Minidrivers are easy to develop because they simply extend generic class driver interface functions. Although minidrivers are simple by design, the benefits of reusable minidriver modules might also be realized in support of standard device programming interfaces. An example of this is the USB host controller interfaces (OpenHCI or UHCI).

The flexibility and uniform interfaces of the modular WDM architecture allows the operating system to dynamically configure various driver modules to support a specific device. A typical driver stack might consist of generic device, protocol, and bus class drivers linked by protocol-specific and bus-specific minidrivers. For example, the operating system can configure a driver stack to support a camera whose commands are defined by the Imaging class and delivered by the Function Control Protocol (FCP) class to the IEEE 1394 bus class. This flexibility also makes it easy to support a multifunction device by simply implementing a minidriver to interface the multifunction hardware to several device class interfaces. The dynamic construction of WDM driver stacks is key to Plug and Play device support.

WDM services enable a common low-latency model for Windows NT and Windows 95. WDM offers multiple levels of execution priority including kernel mode and non-kernel mode threads, IRQ levels, and Deferred Procedure Calls (DPC). All WDM class and minidrivers execute as privileged threads (not interrupted by CPU scheduler) in kernel mode (ring 0). Thirty-two IRQ levels are available to prioritize hardware interrupt service. For each interrupt, a DPC can be queued to execute on completion of the IRQ service routine with interrupts enabled. DPCs enhance system response to interrupts by effectively reducing the time during which interrupts are disabled. For x86-based PC systems that use multiple processors, support under Windows NT for interrupts is based on the MultiProcessor Specification Version 1.4 from Intel.

For applications requiring life-like multimedia, WDM provides low latency interfaces for processing I/O streams in kernel mode. WDM streaming interfaces will be exposed through standard WDM class interfaces. With WDM, a media stream can be processed completely in kernel mode by one or more software filters and device drivers. WDM streaming enables direct hardware access for streaming I/O acceleration, eliminates latency associated with transitions between non-kernel mode and kernel mode, and also eliminates the need for intermediate I/O buffering.

To leverage advances offered by WDM, you are encouraged to build Plug and Play-compatible, power-managed input, audio, imaging, and storage peripherals for USB and IEEE 1394.

WDM drivers can coexist with existing Windows NT drivers on Windows NT and with existing Windows drivers on Windows 95. Existing Windows NT and Windows 95 drivers will continue to be supported, but without the benefits of WDM advances. The extensible WDM class drivers supplied by Microsoft provide the best alternative for new device support. Before beginning development of a new WDM class driver, hardware developers should consult Microsoft for information about support of the particular device class. Whenever possible, class drivers should be written once and extended for specific hardware interfaces by using WDM minidrivers.


References for OnNow and WDM

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Advanced Configuration and Power Interface (ACPI) specification

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

Power management specifications for device and bus classes

http://www.microsoft.com/hwdev/onnow.htm

WDM white papers and information

http://www.microsoft.com/hwdev/pcfuture/wdm.htm

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Microsoft Device Driver Kits (DDKs) for Windows operating systems

Microsoft Developer Network (MSDN) Professional membership


Chapter 3 Basic PC 97

This chapter presents the PC 97 requirements and recommendations for basic PC design under the Microsoft Windows family of operating systems.


Overview for Basic PC 97

Basic PC 97 defines a standard PC (both desktop and mobile) with no particular market category or customer application. This PC is designed to support typical Windows-based applications running under either the Microsoft Windows 95 or Windows NT Workstation operating system.

The new critical design requirements for PC 97 are the following:

  • Support for Advanced Configuration and Power Interface (ACPI), the OnNow design initiative, and Plug and Play for essentially all system components
  • Compliance with specified industry standards for all buses and devices
  • Compliance with guidelines for ease of use for installation, configuration, and daily use of the PC system and peripherals

The Basic PC 97 requirements serve as the basis for all system requirements for the "Designed for Microsoft Windows" logo, with the requirements for Workstation PC 97 and Entertainment PC 97 defined as differences from these basic requirements.

For PC 97, the following definitions are used to distinguish the types of devices present in a PC system:

  • System devices (or system board device) are those devices on the system board such as interrupt controllers, keyboard controller, real-time clock, direct memory access (DMA) page registers, DMA controllers, memory controllers, floppy disk controller (FDC), IDE ports, serial and parallel ports, PCI bridges, and so on. In today's PCs, these devices are typically integrated in the supporting chip set.
  • Add-on devices are those devices traditionally added to the base PC system to add functionality, such as audio, networking, graphics, SCSI controller, dedicated tape backup, uninterruptible power supply (UPS), and so on. Add-on devices fall into two categories: devices built onto the system board, or devices on expansion cards added to the system through a system board connector such as ISA or PCI.

Important The system requirements defined in PC 97 Hardware Design Guide provide guidelines for designing PC systems that best run Windows 95 and Windows NT. These design requirements are not the basic system requirements for running the Windows operating system.

Hardware features are described as Required, Recommended, or Optional for the "Designed for Microsoft Windows" logo program:

  • Required: These basic hardware features must be implemented to qualify for the "Designed for Microsoft Windows" logo.
  • Recommended: These features add functionality supported by the Windows operating systems. For "Designed for Microsoft Windows" logo testing, if a recommended feature is implemented, it must meet the standards for that feature as defined in this guide. Some recommended features might become requirements under the logo program in the future.
  • Optional: These features are neither required nor recommended, but if the feature is implemented in a PC 97 system, it must meet the specified requirements. These features will not become requirements under the logo program in the future.


General System Requirements for Basic PC 97

This section summarizes the requirements and recommendations for the basic components of desktop and mobile systems.

1. Minimum CPU: Pentium-class 120 MHz or equivalent

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
120 MHz Required | 166 MHz Required | 166 MHz Required

This minimum computational capability is required to support the demands of Windows-based applications.

The requirement for RISC-based systems is one of the following:

  • MIPS R4x00 or equivalent
  • Digital Alpha 21064 (EV4) or higher processors
  • IBM PowerPC Architecture for RISC-based systems

Notice that all requirements and recommendations for RISC-based PCs are for the Windows NT operating system only. There are no plans to enable Windows 95 to run on RISC-based PCs.

Note If multiprocessor support is provided in any PC 97 system with x86-based processors, such support must comply with MultiProcessor Specification v. 1.4 or higher (available from Intel).

2. L2 cache with 256K minimum, for Pentium-class processor

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Required

This minimum Level 2 cache is recommended for performance on an x86-based Basic PC 97 system that uses a Pentium-class processor. This requirement does not apply for a system that uses a Pentium Pro-class processor with a built-in L2 cache.

3. Minimum system memory: 16 MB

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | 32 MB Required | Required

Recommended: 32 MB (64 MB for Workstation PC 97).

For Basic PC 97, at least 12 MB of system memory must be completely available for the system to use at boot time and cannot be locked from use by the operating system. For Workstation PC 97, 28 MB of system memory must be available to the system.

Note This minimum requirement for memory available to the operating system does not preclude applications that use dynamically allocated memory for audio or video playback or other temporary uses of system memory.

4. Advanced Configuration and Power Interface (ACPI) support

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

The system board must support the Advanced Configuration and Power Interface (ACPI) Specification v. 1.0 or higher. This requirement ensures that the system correctly supports the Plug and Play and power management functionality described in Part 1 of this guide. ACPI support includes the following:

  • Power management timer.
  • Power button — must comply with the ACPI definition. A separate reset switch is an acceptable alternative to the ACPI-specified override mechanism.
  • Real-Time Clock alarm —wake-up due to a scheduled time and day of month.
  • The S4 "soft off" state, as required in the ACPI specification, plus at least one of the sleep states: S1, S2, or S3. (At least one additional sleep state is required for PC 97, although these states are only recommended in the ACPI specification.)
  • System control interrupt and Status and Enable (STS/EN) bits for the first three features in this list.
  • Description table for system board devices — complete hierarchy including all non-Plug and Play devices to be enumerated and all other devices for which power management or removal capabilities have been added by the system board design.
  • Each bus and device enumerated using ACPI must include the ACPI control methods necessary to configure these devices as described in the requirement, "Each bus and device complies with current Plug and Play specifications," later in this chapter.
  • The USB host controller must be able to wake the system using ACPI mechanisms (required for PC 97, although this support is only recommended in the ACPI specification).

Recommended: The following additional recommendations from the ACPI specification are also recommended for PC 97:

  • Thermal model and fan control. This is recommended as a means of running the PC quietly while working and turning the fan off while sleeping.
  • Support the interface defined in the Intel/Duracell Smart Battery System Specification for reporting battery information. Although other battery interfaces will also be supported, Windows 95 and Windows NT will optimize driver and user interface support to exploit the capabilities of this interface.

Note Any other system board power management or Plug and Play features must be implemented compliant with ACPI, even if a particular feature is not a specific PC 97 requirement or recommendation.

5. Hardware support for OnNow initiative

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Elements of the OnNow design initiative ensure that the operating system and device drivers control the state of individual devices and the system board. The following support is required for PC 97 hardware:

  • The user experiences the PC as "off" when it is in Sleeping state.
  • At a minimum, the hard disks, CD drives, display, sound, input devices, and fans must be perceived as off while the system is in a Sleeping state (for example, no noise and no lights other than the status indicator). However, it is recognized that some CPUs have integrated fans that use CPU power and, hence, the fan cannot be controlled while the CPU is powered. Such CPU fans are exempt from this requirement, as long as the system Sleeping noise requirement is met.
  • The user can easily see whether the PC is Working or Sleeping.
  • This can be implemented as LED status indicators on the front panel, or another solution can be used. At a minimum, the PC 97 system must provide one or more indicators to show whether the system is in the Working or Sleeping state. If telephone answering-machine capabilities are built into the system, then a Message Waiting indicator must also be included on desktop systems. However, the Message Waiting indicator is only a recommendation for mobile systems.
  • The user can easily control power through switches and software.
  • The system must provide an easily accessible power switch that can be controlled by software and that supports the functionality required in the ACPI specification.
  • If the power switch is provided on the keyboard, the hot keys must be labeled clearly and must consist of a single key for turning on the PC. (Two keystrokes are permissible for turning the PC off.) The single keystroke ensures accessibility for persons with disabilities.
  • This requirement does not preclude power-control capabilities related to actions such as closing the lid on a mobile PC.
  • The following shows the scan code for the keyboard power switch:

    VK_POWER = 5E
    Set1-Make: E0, 5E    Set1-Break: E0, DE
    Set2-Make: E0, 37    Set2-Break: F0, 37
  • Power management is supported for all of these buses present on the system: PCI, USB, IEEE 1394, and PC Card.

    Any of these buses present in the system must support power management requirements in the related bus standard, as defined in Part 3 of this guide.

  • Each device supports the power management specifications for its class.

    Each device on the system board or included with the system as an add-on device (either internally or externally) must support the power management reference specification for its device class and be controllable through either ACPI or its bus.

    The device functionality expected in each OnNow power state and the possible Wakeup event definitions for the class are defined in power management specifications for each device class. For more information about these requirements, see the power management sections in the related device class chapters in Part 4 of this guide.

6. BIOS support for OnNow initiative for x86-based systems

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

This requirement applies only for x86-based systems. For PC 97, the OnNow initiative requires the following additional BIOS support:

  • Fast power-on self test (POST). The system must be available to the user quickly. Although a specific time is not required, the basic recommendation is that power-on to bootstrap loader occurs within five seconds plus hard disk ready-time. The following are recommendations for ways to reduce processing overhead to make system boot time as fast as possible:
    • No video memory test and limited test for DRAM size.
    • No tests for serial or parallel port.
    • No floppy disk test or media check (boot from hard disk only).
    • No tests for hard disk controller or drive type (if the system does not include swappable drives).
    • Test execution controlled using a Windows-based control panel or application that can be scheduled to run periodically at off hours.
    • Fast POST mode for BIOS can be disabled by user for troubleshooting.
  • Minimal time for Resume from Sleeping state. Resume from Sleeping state to operating system handoff must occur within 500 milliseconds.
  • Minimal startup display. System startup draws the end user's attention only in case of errors or when there is a need for user action.

    The default configuration must allow a beep during the boot process only in case of an error, and the only screen display allowed is the OEM splash screen, which can include information such as copyright notices. By default, the system must be configured so that the screen display does not display memory counts, device status, and so on, but present a "clean" BIOS startup so that the end user is not presented with cryptic and unnecessary information. However, this requirement does not preclude the following:

    • Presenting a blank startup screen
    • Providing a "hot key" override to display screen messages for troubleshooting or user-definable CMOS settings.
    • Presenting text-based end-user action messages — for example, messages to display the setup hot key, system help hot key, password entry, network login for remote booting, and so on.
    • Presenting manufacturer branding messages.
    • Providing a CMOS option to turn the "clean startup screen" off and on.

    The intention for this requirement is to ensure that the end user is not presented with confusing information and unnecessary visual display, but that access to error information is still available using a hot key.

7. System BIOS support for boot devices, for x86-based systems

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

For any x86-based system that includes CD-ROM as a bootable device, the system BIOS must support the No Emulation mode in "El Torito — Bootable CD-ROM Format Specification Version 1.0," by IBM and Phoenix or an equivalent method that supports the Windows NT CD-ROM installation process.

For any x86-based system that includes a network adapter as a boot device, the system BIOS must comply with the requirements defined in section 3 and 4 (as they apply to Plug and Play devices) of the Compaq, Phoenix, Intel BIOS Boot Specification v. 1.01 or higher, which describes the requirements for Initial Program Load (IPL) devices.

8. BIOS boot support for USB keyboard, if USB is the only keyboard

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

For any x86-based system with a USB keyboard as the only keyboard in the system, the system BIOS must provide boot support for USB keyboards. The specification for this support is defined in "Universal Serial Bus PC Legacy Compatibility Specification," v. 1.0 or higher, available from:

http://www.teleport.com/~usb/data/usb_le9.pdf.


Industrial Design Requirements for Basic PC 97

This section summarizes physical design requirements and recommendations for PC 97 systems. These requirements are in addition to those related to the OnNow initiative for power-state indicators and easily accessible power switches.

9. All expansion slots in the system are accessible for users to insert cards

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

The expansion slots cannot be physically blocked by components or devices provided with the system. This requirement does not exclude configurations that allow space for only half-height cards for some slots or passive back planes used for connectors, and so on.

10. Audible noise meets PC 97 standards

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

A PC 97 system should be "silent" in the Sleeping state, and an Entertainment PC 97 system must also be quiet during active operations, including hard-disk seek activities. Recommended test procedures and measurements will be documented by Microsoft.

The need to limit audible noise comes from the OnNow design initiative. A PC that uses OnNow technologies will be active even when not under direct operation by the user. For example, OnNow PCs will perform scheduled and background tasks such as receiving faxes and voice mail, checking e-mail, and downloading Internet information using a modem. These operations must happen silently so as not to interfere with other activities in the home or at work.

11. System and component design practices follow accessibility guidelines

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

Accessibility design guidelines are provided in Appendix C, "Accessibility," in this guide. These guidelines were developed in consultation with the Trace Research and Development Center at the University of Wisconsin. This recommendation will not become a requirement.


General Device Requirements for Basic PC 97

The requirements in this section apply for every device, whether it is present on the system board or as an expansion device provided by the OEM in a default system configuration. Most general device requirements are related to Plug and Play capabilities.

12. Each device and driver meets PC 97 device requirements

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Each device, whether provided in the PC system, as an expansion card, or as an external device, must comply with all PC 97 requirements for the related device class and must have supporting device drivers that work for both Windows 95 and Windows NT, as tested by Microsoft WHQL. This includes support for power management IRPs (for WDM drivers) or messages (for VxD drivers) if power management hardware is nonstandard.

In addition to the device requirements in this section, see also the requirements for specific device classes in Part 4 of this guide.

13. Each bus complies with written specifications and PC 97 requirements

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

In the past, some bus designs did not fully implement all of the bus requirements on every expansion card connector. Each bus used in the system must meet all the requirements for that bus, as defined in Part 3 of this guide.

14. Each bus and device complies with current Plug and Play specifications

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Each bus and device provided in a PC 97 system must meet the current Plug and Play specifications related to its class, including requirements defined in the ACPI specification and clarifications published for some Plug and Play specifications. This includes requirements for automatic device configuration, resource allocation, and dynamic disable capabilities.

There is only one change to Plug and Play specifications from those defined in 1995: the addition of SCANNER and DIGCAM as new CLASS key values for Plug and Play parallel devices.

The following shows current version numbers for all Plug and Play specifications:

  • Plug and Play BIOS Specification v. 1.0a
  • Clarification to Plug and Play BIOS Specification v. 1.0a
  • Plug and Play ISA Specification v. 1.0a
  • Clarification to Plug and Play ISA Specification v. 1.0a
  • Plug and Play SCSI Specification v. 1.0
  • Plug and Play Parallel Port Device Specification v. 1.0b
  • Plug and Play External COM Device Specification v. 1.0

The following specification provides an optional format for non-volatile storage of configuration information for PCs where form factors limit available non-volatile storage. This specification is not a PC 97 requirement:

  • Extended System Configuration Data Specification v. 1.02a or higher

Note Standard system devices are excluded from the Plug and Play requirement. The system can reserve static resources for standard devices such as interrupt controllers 1 and 2, timer (8254-2), keyboard controller (8042), real-time clock, DMA page registers, DMA controllers 1 and 2, and math coprocessor (if present). For an x86-based system, these fixed resources are located at I/O addresses under 100h and can also include an NMI mask. For more information, see Appendix D, "Legacy I/O Assignments."

15. Unique Plug and Play device ID for each system device and add-on device

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Each device connected to an expansion bus must be able to supply its own unique identifier. Each type of bus contains different information for uniquely identifying devices on expansion cards. For more information, see the chapters for particular bus designs in Part 3 of this guide.

  • Each separate function or device on the system board must be enumerated separately, so each must provide a device identifier in the manner required for the bus it uses.
  • If a device on an expansion card is enumerated by the BIOS, it must have a unique identifier and its own resources according to the PC 97 device-ID requirements for the bus to which the card is connected. This includes devices that are separately enumerated on multifunction cards or multifunction chips.

    CardBus devices must meet the requirements defined in the "PC Card" chapter in Part 3 of this guide.

The following are exceptions to this requirement:

  • Legacy devices attached to the ISA bus on the system board do not have unique Plug and Play identifiers (for example, serial ports, parallel ports, or PS/2-compatible port devices). The method for device identification is defined in the Plug and Play ISA Specification v. 1.0a.
  • Some multifunction devices (such as SuperI/O) might include devices that do not each have unique Plug and Play IDs or unique PCI subsystem IDs, but that are supported by standard drivers under the Windows operating system.
  • A device such as a multifunction PCI device that supports a number of functions but uses only a single set of relocatable resources does not have to provide separate identifiers for each function included on the device.

16. Option ROMs meet Plug and Play requirements (for x86-based systems)

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

This requirement applies only for x86-based systems for any devices that might use option ROM, whether the device is present on the system board or provided through an expansion card. Related option ROM requirements are also defined for specific bus classes and specific devices, such as SCSI and graphics adapters, respectively.

For x86-based systems, option ROMs are usually located on cards used as system boot devices. During the boot process, option ROMs initialize the boot devices, which provide the primary input, primary output, and IPL device to boot the system. However, Plug and Play option ROMs can be used to supply the Plug and Play expansion header to devices other than boot devices, enabling them to initialize both devices when the system boots.

To design an option ROM with Plug and Play capabilities, follow the requirements described in the Plug and Play BIOS Specification, which discusses the Plug and Play expansion header and the interaction between the system BIOS and the option ROM. In particular, note the following points from the specification:

  • The header contains information that identifies the type of boot device connected to the expansion card and allows the system BIOS to prioritize the boot devices. Shadowed copies of the option ROM must also contain the Plug and Play expansion headers.
  • A Plug and Play option ROM must be able to determine whether the system BIOS complies with Plug and Play. If the system ROM is not Plug and Play compliant, the option ROM should immediately initialize the card and hook the proper interrupt as though it were a non – Plug and Play option ROM. This allows the expansion card to be used in non – Plug and Play systems.
  • Option ROMs can use the system BIOS run-time functions, but these functions are not available until after the POST process has completed and Int 19 has been called. In particular, an option ROM must not hook the following interrupts until the system BIOS calls the boot connection vector contained in the Plug and Play expansion header: Int 9h, Int 10h, Int 13h, Int 18h, or Int 19h. Option ROM routines must not try to use these run-time functions until that time, because the results can be unpredictable.

Option ROM requirements for specific devices are defined in the "ATA and ATAPI" and "SCSI" chapters in Part 3, and also in the "Graphics Adapters" chapter in Part 4 of this guide.

17. "PNP" vendor code used only to define a legacy device's CompatibleID

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

All ISA and other legacy devices not enumerated by the system board interface must not use "PNP" in their Vendor and Device codes. The "PNP" vendor code is reserved for Microsoft and the vendors whose hardware is specifically assigned a particular ID. Other hardware can only use a "PNP" code when defining a device's CompatibleID after first indicating the device's HardwareID in the Plug and Play header.

For non-BIOS enumerated ISA devices, rather than using "PNP" in the vendor ID code, vendors must register any new vendor IDs by sending e-mail to pnpid@microsoft.com. For information about using "PNP" CompatibleIDs, see Appendix B, "Device Identifiers."

Use of CompatibleIDs is strongly recommended for devices that use device drivers provided with the Windows operating system, such as a "Standard PC COM Port" (PNP0500) or "Sound Blaster 16-compatible Sound Device" (PNPB003).

18. All devices support correct 16-bit decoding for I/O port addresses

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Each device must support a unique I/O port address in the 16-bit address range. This requirement means, at a minimum, the upper address lines A10 – A15 can be used as device enable, so the device does not respond to addresses outside of the 10-bit address range. CardBus controllers and cards must meet the requirements defined in the "PC Card" chapter in Part 3 of this guide.

Devices that that use less than 16-bit I/O decode create conflicts that cannot be resolved by a Plug and Play operating system. Phantom (alias) addressing is not supported by the Windows operating system and cannot be used to meet the PC 97 requirements.

Notice, however, that this requirement does not apply for the three ISA auto-configuration registers used during device enumeration and configuration. The ADDRESS, WRITE_DATA, and READ_DATA registers will continue to use 12-bit decoding as described in the ISA Plug and Play specification.

19. Devices and buses support hot plugging if using USB, 1394, or PC Card

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Any bus or device designed to use USB, IEEE 1394, or PC Card (which all support hot plugging) must support being added or removed while the system is fully powered.

20. The user is protected from incorrectly connecting devices

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

This requirement is to help ensure that the end user can correctly make the physical connections required for adding a device in the system. This requirement includes the following:

  • Wherever possible, keyed or shrouded connectors or other configurations should be used to prevent misconnection.

    The physical design of the connector must ensure that the user cannot mistakenly insert the connector in the wrong port. For specific requirements related to keying connectors and cables for I/O controllers and peripherals, see the "ATA and ATAPI" chapter and "SCSI" chapter in Part 3 of this guide.

  • Icons are provided for all external connectors.

    The icons can be molded, printed, or added as permanent stickers (which can include text). Icons can be based on existing vendor designs or on suggestions listed in the "Icons" appendix.

    For mobile PC designs with small-height considerations, connector icons might not fit on the back of the case. In such cases, it is acceptable to wrap the icons to the bottom of the unit or on the inside of an access door.

Note It is recognized that the design for legacy ports such as the PS/2-compatible mouse and keyboard ports, analog audio and video jacks, and the microphone and speaker jacks will not change, and therefore cannot fully meet this requirement. However, icons and labels must be provided wherever possible to assist the user in making correct connections.

21. Minimal user interaction needed to install and configure devices

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

After physically installing the device, the user must not be required to perform any action other than to insert disks that contain drivers and other files. The user should have to restart the system only for devices that do not support hot plugging. As specified earlier in this section, devices that use USB, IEEE 1394, or PC Card must support hot plugging. For devices that use other buses, detection occurs when the system is powered on after the device is inserted.

  • The device is functional immediately without restarting the system.

    It is acceptable to require rebooting for primary system devices such as the primary graphics adapter, the primary hard-disk controller, and any ISA boot device.

    In all cases, however, changing configuration settings still must not require jumper changes.

  • Software setting are available for configuring all resources.

    All buses and devices on both the system board and all expansion cards must be capable of being configured by the operating system and by software such as Device Manager in Windows 95, so the user does not need to open the PC case to change the configuration. DIP switches on boot devices can be used for an initial power-on default state or for non – Plug and Play system compatibility, but must be able to be overridden by software configuration after power-up.

    Note This does not exclude jumper settings that the OEM configures to define CPU speed, select a keyboard, or make other system-related settings. This requirement excludes only jumper settings that the end user must make to configure the hardware.

  • Dynamic disable capabilities are supported for all devices.

    All devices must be capable of being disabled automatically by the system. Also, disabling the device must result in freeing all its resources for use by other devices.

    The following devices are exempt from the requirement for dynamic disable capabilities: all legacy devices using the I/O range under 100h, keyboard controller, floppy disk controller, hard disk controller, VGA memory and I/O addresses, and any BIOS memory ranges required for legacy boot support.

22. Device driver and installation meet Windows and Windows NT standards

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Each device must have drivers for both Window 95 and Windows NT to ensure correct support under both operating systems. For some device classes, this support can be provided using a WDM driver, as defined in the specific requirements for devices in Part 4 of this guide.

The manufacturer does not need to supply a driver if a standard driver provided with the operating system can be used. If the manufacturer supplies drivers, the requirements for device drivers and installation include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.

    Each device included in a PC 97 system must comply with the "Designed for Microsoft Windows" logo requirements and must have supporting 32-bit device drivers for the CPU platform and the operating system.

  • All configuration settings are stored in the registry.

    The driver must not use INI files for configuration settings.

  • The correct minidriver, VxD, or any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations.

    For manufacturer-provided files, the vendor must not be identified as Microsoft, and all other copyright and version information must be correct for the manufacturer.

  • Driver installation and removal use Windows-based methods.

    Drivers must be installed using Windows-based methodology only as defined in the Windows 95 and Windows NT DDKs. The device driver must be able to be removed using Windows-based software, which can be managed using either the Windows Control Panel option for removing devices or using its own remove utility. For information, see these topics in the DDKs:

  • "Windows 95 Class Installers and Network Driver Installers" in the Windows 95 DDK
  • "Driver Installation" in the Win32 DDK

    However, any software applications included with the device can be installed using an alternate Windows-based installation method as defined in the Win32 SDK.

  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems and provided as either retail or OEM products, unless specifically agreed with Microsoft.
  • Only 32-bit, protected-mode components are installed. No real-mode or 16-bit protected-mode components can be provided in order to operate under Windows. (An exception for Windows 95 graphics drivers is noted in the "Graphics Adapters" chapter in Part 4 of this guide.)

    Any real-mode components provided for backward compatibility should use a separate installation procedure. Although installation of Windows-based components must not make entries in Autoexec.bat or Config.sys, the separate real-mode installation program can make such entries, but must not modify the registry, Win.ini, or System.ini.

  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).
  • For device classes where support using WDM drivers is provided in the operating system, the driver supplied by the manufacturer must be a WDM minidriver.

23. Multifunction add-on devices meet general device requirements for each device

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Multifunction add-on devices can contain more than one device. Multifunction add-on devices must meet the standards defined earlier in this section for automated software-only settings for device configuration, standard device drivers, and Windows-based installation. In addition, the following requirements must be met:

  • Each function or device on the multifunction add-on device that is individually enumerated by the BIOS must provide a device identifier for the bus it uses.
  • The system must be able to access separately each logical device that is individually enumerated by the BIOS, configure the device resources independently, and disable individual devices in the event of a conflict.
  • For each individually enumerated device, resource configuration requirements are the same as for an equivalent device on a separate expansion card. This requirement means that registers cannot be shared between individually enumerated devices on a multifunction add-on device, but does not supersede device requirements among different bus classes.

The exception to this requirement is a device such as a multifunction PCI device that supports several functions but uses only a single set of relocatable resources. When each device is not individually enumerated, there is no requirement to provide separate identifiers and separate resources for each function on the device.

24. Standard system board devices use ISA-compatible addresses

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

For x86-based systems, this includes devices with I/O port addresses within the reserved range 0h through 0ffh. For information about legacy system I/O addresses, see Appendix D, "Legacy I/O Assignments."


Basic PC 97 Buses and Devices

This section defines specific requirements for buses and devices provided in a PC 97 system, in addition to the basic requirement for supporting the Advanced Configuration and Power Interface specification, as defined earlier in this chapter.


System Buses for Basic PC 97

This section defines the general requirements for system buses. Additional requirements are defined in Part 3 of this guide for particular buses.

25. Universal Serial Bus with one USB port, minimum

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required, with 2 USB ports

Recommended: 2 ports. Universal Serial Bus (USB) provides a bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, communications devices, and input devices on a single bus.

The USB implementation in the system must meet the requirements defined in USB specifications, plus any additional requirements for PC 97 defined in the "USB" chapter in Part 3 of this guide.

26. Support for other high-speed expansion capabilities

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | IEEE 1394 Required
CardBus Required for mobile |  |

Additional support for expansion capabilities can be provided using PCI v. 2.1, IEEE 1394, CardBus, or other high-speed buses. For a mobile PC, one CardBus slot is required, and two slots are recommended. Any expansion bus implemented in the system must meet the requirements defined in the related chapter in Part 3 of this guide.

27. If present, PCI bus meets PCI v. 2.1 and higher, plus PC 97 requirements

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

If PCI is used in a PC system, the PCI bus must meet the requirements defined in PCI v. 2.1 or higher, plus any additional requirements for PC 97 defined in the "PCI" chapter in Part 3 of this guide. Exceptions for particular devices are noted in Part 3 and Part 4.

For example, add-on PCI IDE devices must comply with PCI 2.1 requirements and also provide Subsystem IDs and Subsystem Vendor IDs, but PCI-to-PCI bridges and core chip sets do not have to provide Subsystem IDs and Vendor Subsystem IDs.

28. ISA expansion bus

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Optional | Optional | Optional

It is recommended that system designers consider not providing expansion capabilities using the ISA bus in PC 97 systems and that all hardware vendors plan for migration away from ISA in their product lines. However, the PC system designer might choose to include the ISA expansion bus to support customers who want to "recycle" legacy add-on hardware.

If ISA is implemented in a PC 97 system, the following is required:

  • Complete Plug and Play support must be implemented as defined in Plug and Play ISA Specification v. 1.0a. For x86-based systems, this includes support in the system BIOS and support for ISA option ROMs. These requirements include a means for identifying the Plug and Play capabilities of the option ROM and enabling the option ROM to determine whether the system BIOS is compatible with Plug and Play.
  • Resource configuration requirements are specified for each physical port or device on the system and cannot be split among devices of the same type. This ensures true Plug and Play resource assignment and conflict resolution in the system. These minimum resource requirements are defined in the chapters for specific device classes in Part 4 of this guide.

    If the device cannot meet the resource requirements defined for PC 97, ISA IRQ sharing must be supported in the hardware and driver for an ISA device by using the operating system support first provided in 1996 for Windows 95.

  • As specified in the Plug and Play ISA specification, a card must have both an industry-unique Vendor ID and a company-unique Product Identifier. This means that each different product and model from the same manufacturer must have a different product identifier to ensure that the operating system can isolate and identify these different cards.

    The use of a unique serial number is strongly recommended. To avoid problems that can occur when a user installs two of the same cards in a PC system, the Plug and Play ISA specification defines a unique serial number field that can be added to the Vendor and Product IDs to make the card completely unique. If unique serial numbers are not supported, the Serial Number field must contain 0xFFFFFFFF, as required in the Plug and Play ISA specification.

  • The system BIOS must properly configure all Plug and Play ISA cards in the PC system if a non – Plug and Play operating system is loaded.

Notice that including ISA in the system will probably require support for traditional keyboard, parallel, and serial ports. For related requirements, see the "Serial, Parallel, and Wireless Support" and "Input Components" chapters in Part 4 of this guide. For a complete list of ISA requirements for PC 97, see the "ISA" chapter in Part 3 of this guide.


I/O Devices for Basic PC 97

This section defines the general requirements for I/O devices. Additional requirements are defined in the sections titled "Graphics Adapter and Monitor for Basic PC 97" and "Storage and Related Peripherals for Basic PC 97" later in this chapter.

29. Keyboard connection and keyboard

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | USB or Wireless Required

Recommended: USB. The external connection requirements on any PC can also be met using a PS/2-style or AT-style port or wireless capabilities in the system. A mobile or all-in-one system that has a built-in keyboard must also provide the capability for an external keyboard connection, which can be implemented using a port replicator or a single PS/2-style port with special cabling for both external keyboard and mouse. For complete requirements for keyboard ports and peripherals, see the "Input Components" chapter in Part 4 of this guide.

30. Pointing device connection and pointing device

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | USB or Wireless Required

Recommended: USB or other external bus. The external connection requirements on any PC can also be met using a PS/2-style port or wireless capabilities in the system. A mobile or all-in-one system that has a built-in pointing device must also provide the capability for an external mouse connection, which can be implemented using a port replicator or a single PS/2-style port with special cabling for both external keyboard and mouse. A second serial port is not recommended as the external connection for a pointing device. For complete requirements for mouse ports and peripherals, see the "Input Components" chapter in Part 4 of this guide.

31. Connection for external parallel devices

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Recommended: USB or other external bus. This can also be provided as a parallel port with ECP mode capabilities. For complete requirements for parallel ports, see the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

32. Connection for external serial devices

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Recommended: USB or PC Card. This can also be provided as a 16550A serial port. For complete requirements for serial ports, see the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

33. Wireless capabilities in PC system

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

If wireless capabilities are included in the system, PC 97 requirements must be met, as defined in the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

34. Support for installing the operating system

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

The PC 97 system must include I/O device support (and system BIOS support for boot devices, as described earlier in this chapter) to allow the user to install (or reinstall) the operating system. This support can be included as one of the following types of devices, depending on specific customer requirements:

  • CD-ROM drive

    If this device is present, the host controller must meet requirements defined in the related chapter in Part 3 of this guide, and the device must meet the requirements defined in the "Storage and Related Peripherals" chapter in Part 4 of this guide.

  • Network adapter

    If the network interface is implemented in the PC system (either on the system board or through an expansion card), the network adapter must meet the requirements defined in the "Network Communications" chapter in Part 4 of this guide.

  • Floppy disk drive: 3.5", 1.44 MB minimum capacity

    Support for a floppy disk drive can be provided using PC Card or USB or a legacy FDC device, as defined in the "Storage and Related Peripherals for Basic PC 97" section later in this chapter.

For the Windows NT operating system, either a CD-ROM drive or network adapter must be included in the system, because Windows NT does not support installing the operating system from a floppy disk drive.

Note It is recognized that OEMs supply PC systems to corporations with specific feature requirements. For example, a customer might want to insert network adapters at the end-user site and might require no local storage devices for remote-boot, diskless workstations. PC systems designed for specific corporate customer features are exempt from this PC 97 requirement.

35. Audio support in PC system meets PC 97 requirements

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Advanced audio Required

Recommended: PC 97 Advanced audio. Audio in a PC 97 system — whether it is implemented as baseline audio built into the PC system or PC 97 Advanced audio — must meet the minimum requirements defined in the "Audio Components" chapter in Part 4 of this guide.

36. Communications device provided with PC system

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Required

If a modem or networking adapter is implemented in the PC system, the device must meet the requirements defined in the "Modems" chapter or "Network Communications" chapter in Part 4 of this guide.


Graphics Adapter and Monitor for Basic PC 97

This section summarizes the PC 97 requirements for the graphics adapter and monitor. For complete details related to basic graphics adapter requirements, including recommendations for hardware acceleration, see the "Graphics Adapters" chapter in Part 4 of this guide.

37. Display adapter meets PC 97 minimum requirements

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
800x600x16 bpp | 1024x768x16 bpp | 1024x768x16 bpp
640x480x8 bpp, small LCD |  |

A Basic PC 97 system must contain a graphics adapter that permits a color depth of 16 bpp, minimum.

  • Minimum resolution:
    • Basic PC 97: 800x600x16 bpp for Windows desktop and 640x480x16 bpp double buffered for DirectDraw-based full-screen applications.

    The minimum required resolution for a 7"– 10" LCD internal display is 640x480x8 bpp.

    • Workstation PC 97: 1024x768x16 bpp.
    • Entertainment PC 97: 1024x768x16 bpp.

    Display RAM requirements are tied directly to the minimum graphics resolution supported by the adapter. The requirement to support double buffering implies 1.5 MB of display RAM. However, PC 97 requirements do not specify minimum display RAM support; rather, the adapter designer can implement any solutions for supporting the minimum resolution requirements.

  • Primary graphics adapter does not use legacy bus

    For the primary graphics adapter, the video bus must not use ISA. A higher-performance solution is required to optimize performance of the packed-pixel frame buffer. Possible implementations that meet this requirement can include PCI v. 2.1 for all system types or the Intel Accelerated Graphics Port 1.0 (AGP) interface for systems that have Pentium Pro-class processors. If the graphics adapter uses the PCI bus, it must comply with PCI v. 2.1 and additional requirements defined in the "PCI" chapter and the "Graphics Adapters" chapter in this guide.

  • System operates normally with default VGA mode driver

    The default VGA driver is required for installing the operating system. The adapter must support 4-bit planar VGA mode as described in the Windows 95 DDK.

  • Support for multiple adapters and multiple monitors

    This support ensures that the end user has guaranteed, automatic support for installing and using another graphics adapter, and support for simultaneous display on two or more monitors. The requirement is related to new capabilities in the Windows operating system. This requirement ensures baseline support in the hardware to allow the operating system to correctly configure use of multiple monitors or multiple graphics adapters. For complete information, refer to the "Graphics Adapters" chapter in Part 4 of this guide.

38. Support for NTSC or PAL TV output, if no large-screen monitor

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

This recommendation will not become a requirement for the Basic PC system in the future. For complete information, refer to the "Graphics Adapters" chapter in Part 4 of this guide.

39. Color monitor supports DDC 2.0 Level B, EDID, and 800x600, minimum

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

A monitor designed for or included with a PC 97 system must be compliant with Display Data Channel Standard v. 2.0, Level B (DDC2B), which defines the communication channel between the display and host system. In addition, the monitor must transmit an Extended Display Identification Data (EDID) structure containing unique ID Manufacturer Name and ID Product Code identifiers, and all required fields as described in Section 3 of Extended Display Identification Data Standard 2.0 (or higher).

For complete PC 97 requirements for monitors, including requirements for image color matching (ICC), ergonomic timing standards, and DDC support, see the "Video Components" chapter in Part 4 of this guide.

40. System supports MPEG-1 playback

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Microsoft provides operating system support through Microsoft ActiveMovie. For information about performance and graphics hardware requirements to support video playback, see the "Video Components" chapter in Part 4 of this guide.

41. PC 97 DVD playback requirements, if PC system includes DVD-Video

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required with DVD-Video | Required with DVD-Video | Required

All PC 97 systems that include DVD-Video support must provide PC 97 playback support for DVD content, as defined in the "Video Components" chapter in Part 4 of this guide. For other requirements related to DVD if it is implemented in a PC system, see the "Storage and Related Peripherals" chapter in Part 4 of this guide.


Storage and Related Peripherals for Basic PC 97

This section summarizes the requirements for storage devices for PC 97. For system requirements related to CD-ROM and floppy disk drives, see the "System Buses and I/O Devices for Basic PC 97" section earlier in this chapter.

42. Support Int 13h Extensions in system and option ROMs

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

This requirement applies only for x86-based systems. The Int 13h Extensions ensure correct support for high-capacity drives. Support for the "fixed disk access" subset of Int 13h Extensions must be provided in the system BIOS and in any option ROMs for storage devices that include BIOS support. The Int 13h Extensions are defined in "Int 13h Extension APIs" in the Layered Block Device Drivers section of the Windows 95 DDK.

43. Host controller for storage device meets PC 97 requirements, if present

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

If present in the PC 97 system, the host controller must meet requirements defined for the bus it uses; for SCSI or IDE controllers, it must also meet the requirements in the "ATA and ATAPI" or "SCSI" chapter in Part 3 of this guide.

44. Primary host controller supports bus mastering

Basic PC 97 | Workstation PvC 97 | Entertainment PC 97
Recommended | Required | Required

The primary host controller should support bus mastering, whether using IDE, SCSI, or IEEE 1394. Bus mastering support should also be enabled for IDE devices, including hard disks, CD-ROM, and tape drives.

Bus master capabilities, if implemented, must meet the related specification for the particular controller. For example, the programming register set for PCI IDE bus master DMA is defined in Small Form Factor (SFF) 8038i.

Note This recommendation will become a requirement in 1998. This recommendation does not apply to legacy floppy disk controllers, and will not become a requirement for the floppy disk controller.

45. Hard drive meets PC 97 requirements, if present

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

If present in the PC 97 system, the hard disk drive must meet the requirements defined in the "Storage and Related Peripherals" chapter in Part 4 of this guide; for SCSI or IDE peripherals, it must also meet the requirements in the "ATA and ATAPI" or "SCSI" chapter in Part 3 of this guide.

46. Media status notification support for removable media

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

IDE and ATAPI removable devices must follow the Microsoft specification named Media Status Notification v. 1.03 or higher (included in SFF 8020i v. 2.6 in 1996). SCSI devices must follow the Media Status Notification Support Specification for SCSI and ATAPI Devices v. 1.0 or higher.

47. Legacy floppy disk controller built into system

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Optional | Optional | Optional

Recommended: floppy disk capabilities provided through expansion card or external bus. To support migration away from legacy devices for PC 97, it is recommended that support for floppy disk drives be provided by using a solution based on an external bus such as USB, IEEE 1394, PC Card, or a peripheral device that uses SCSI or IDE. If a legacy FDC is included on a PC 97 system, it must meet the requirements defined in the "Storage and Related Devices" chapter in Part 4 of this guide.


Mobile PC and Form-Factor Related Requirements

This section summarizes exceptions and additional requirements for mobile PCs and provides requirements for docking stations and port replicators.

Note PC 97 Hardware Design Guidelines do not apply for so-called personal digital assistants (PDAs) or other sub-PC form factor designs.

The following is a specific requirement for mobile PCs.

48. CardBus for high-speed expansion capabilities on mobile PCs

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

One CardBus slot is required; two slots are recommended. For more information about the PC 97 requirements for implementing CardBus, see the "PC Card" chapter in Part 3 of this guide.


Mobile PC Design Exceptions and Clarifications

A few design exceptions are called out in the Basic PC 97 requirements in regards to capabilities that cannot be met on mobile PCs because of form factors issues or limitations in chip designs for mobile units. Exceptions and clarifications for general system design and general device requirements for mobile PCs are the following:

  • All expansion slots are accessible: It is recognized that the fan and heat sink on the CPU or Overdrive processor might block full-sized add-on devices from being installed in some slots in mobile PCs or other small form factor system boards. However, notice that it is acceptable to allow space for only half-height cards for some slots or passive back planes used for connectors, and so on.
  • Hardware support for OnNow initiative:
    • The power switch control requirements do not preclude power-control capabilities related to closing the lid on the mobile unit.
    • The Message Waiting indicator is only a recommendation for mobile PCs.
  • General device requirements: The battery in a mobile unit is a device that must meet the requirements defined in "General Device Requirements for Basic PC 97" in this chapter.
  • User cannot physically connect devices incorrectly: Connector icons can wrap to the bottom of the mobile unit or inside an access door when they don't fit on the back of the case.

Exceptions and clarifications for system buses on mobile PCs are the following:

  • Universal Serial Bus: The refinements to the USB specifications for power and timing for mobile PCs are PC 97 requirements for power management. For mobile units, USB must be built into the PC, not provided solely by port replications or docking stations, although these units can provide extra USB connectors.

    For Entertainment PC 97, it is recognized that there might be no room for two USB connectors on a mobile PC unit. However, for a docking pair, a second USB connector can be provided on the docking station.

  • Other high-speed expansion bus: A mobile PC design can include an expansion bus for connecting a docking station or port replicator.

Exceptions and clarifications for I/O devices on mobile PCs are the following:

  • Connections for external keyboard and pointing device: The requirement for external connections for the keyboard and pointing device can be met by implementing a single PS/2 port and providing a special cable that allows both the external keyboard and the mouse to use the single port.

    The external connection can also be implemented on the port replicator for a mobile unit that includes such a device.

    A second serial port is not a recommended design solution for an external mouse connection on a mobile PC.

  • Connection for external parallel and serial devices: These capabilities can be provided on a port replicator or on the docking station for a docking pair.
  • Audio meets PC 97 requirements: It is recognized that baseline audio is built into the mobile unit on the system board. For mobile PCs, the signal-to-noise requirement is 75 dB from 20 Hz to 15 kHz, A-weighted, as noted in the "Audio Components" chapter in Part 4 of this guide.

Exceptions and clarifications for graphics on mobile PCs are the following:

  • Display adapter resolution minimum: Minimum resolution is specified as 640x480x8 bpp for small LCD displays such as those used for the internal display on mobile PCs. The display adapter for external displays must meet the resolution requirements and all other minimum requirements as defined in the "Graphics Adapters" chapter in Part 4 of this guide.
  • Hardware support for video playback. Hardware arithmetic stretching and YUV off-screen surfaces for color space conversion are recommended but not required for the internal display on mobile PCs.
  • ICC color matching for monitors. This is a recommendation for LCD, color plasma displays, or other flat panel devices. This will become a requirement.


Docking Station Requirements

Docking systems for mobile PCs allow docking of a PC with additional hardware capabilities. A docking station adds capability to a mobile PC that allows the end user to add other devices to the system — for example, sound, network adapter, hard disks, CD-ROM, different display adapter, SCSI, modems, and so on.

Resource conflicts can occur with a mobile PC that is paired with a docking station if the docking station contains an expansion bus that allows users to add non-proprietary expansion cards to the system. For a mobile PC-and-docking station pair, the system designer must ensure that the docking system is capable of arbitrating resources for conflicts that might occur if an expansion card is added to the docking station. However, the system designer does not need to add to the mobile PC unit all of the Basic PC 97 resource-arbitration capabilities.

49. Mobile unit and docking station meet PC 97 requirements as a pair

Required

Manufacturers who submit a mobile PC unit that has a docking station companion for "Designed for Microsoft Windows" logo testing must submit the combined docking station and mobile PC for testing, and this combination must pass WHQL testing.

50. Docking station meets ACPI requirements

Required

The Advanced Configuration and Power Interface (ACPI) specification, as discussed in Part 1 of this guide, ensures support for recognizing and managing docking and undocking events and the related power states and resource requirements.

51. Docking station meets all Basic PC 97 requirements for general devices, expansion cards, system bus, and system board

Required

This is required if the docking station allows addition of non-proprietary devices, but is not a requirement if the docking station does not allow addition of non-proprietary devices. These requirements are defined earlier in this chapter.

52. Automatic resource assignment and dynamic disable capabilities for mobile/docking station pair

Required

The mobile PC unit that is part of a docking system does not require all of the resource-arbitration capabilities required for expandable PC systems. However, the system as a whole must be capable of dynamically disabling add-on devices completely and freeing all the resources used by that device when the mobile unit is docked. (This requirement excludes fixed-resource devices, such as the DMA controller, interrupt controller, and so on.)

With this capability, individual devices in the mobile PC will be disabled when it is docked, allowing the appropriate devices in the docking station to be enabled.

The system could fail if an add-on card requires resources that conflict with a device on either the mobile PC or the docking station. The mobile/docking station combination must be able to resolve resource conflicts between all the devices in the docking system.

This means that docking-station devices must be available to replace disabled devices in the mobile PC, and these devices must meet the basic resource arbitration requirements for PC 97, as described earlier in this chapter. However, it is up to the design engineer of a mobile/docking station combination to determine which component (mobile or docking station) will resolve the conflict when the mobile unit is docked.

53. Fail-safe docking

Required

The system must provide a fail-safe system for docking and undocking the mobile unit. Working in conjunction with the operating system and ACPI, the mechanism for fail-safe docking must ensure the following:

  • The undock button signals the user's intent to the system.
  • Docking can occur only when the mobile unit is in the correct power state. (The power state depends on whether the system is designed to support cold, warm, or hot docking.)
  • The user can initiate undocking through Windows-based software choices. Notice, however, that a hardware "button" must also be provided, because experience shows that users often do not find the software option and remove mobile units without operating-system notification.
  • The undock button or software choice sends signal to the operating system, so that the user is warned if resources in use are in danger of being lost.
  • A safe undock indicator is provided so that user can identify when it is safe to remove the mobile unit. This can be an LED light or any other mechanism chosen by the vendor. If a physical mechanism automatically undocks the mobile PC or if hot docking is supported, then the "safe undock" indicator is not required.

There is no requirement for mechanical lockout to block the user from removing the mobile unit without operating system notification.


Port Replicator Requirements

A port replicator duplicates externally and extends features that are already available in a mobile PC — for example, providing an extra PC Card slot.

A port replicator with dedicated features allows the end user to add a specific feature to the original mobile PC — for example, providing a CD-ROM drive when the mobile unit does not have such a drive.

A mobile PC with a port replicator does not need to meet the expansion card requirements defined for Basic PC 97, and also does not need to meet all the resource requirements of a mobile/docking station combination. A port replicator is not required to provide an undock or eject button.

However, some mobile PC system designs include a port replicator that has dedicated features for networking, additional PC Card slots, CD-ROM, and so on. This means that the system could have additional resource requirements so that all available IRQs in the system are already allocated; and therefore the PC Card slots (for example) would not have any IRQs available, rendering them useless. In such cases, the port replicator must contain devices that replace any devices in the mobile PC that do not meet the resource requirements for a PC 97 computer.

54. Automatic resource assignment and dynamic disable capabilities for replacement devices

Required

A port replicator that can accept expansion cards must contain devices that replace any devices in the mobile PC that do not meet Basic PC 97 requirements for IRQ, DMA, I/O port, and memory resources. This allows the operating system to disable the device on the mobile PC, enable the corresponding device on the port replicator, and then arbitrate resources among the remaining devices in the mobile unit and the devices on the port replicator.

Devices in the system must be capable of being disabled dynamically, so that the user can choose to free resources in order to allow other devices in the system to function. For ISA devices included with the PC system that do not otherwise meet the resource requirements defined for PC 97, the system designer must implement IRQ sharing for ISA, as described in the "ISA" chapter in Part 3 of this guide.


Multimedia PC Guidelines for PC 97

Entertainment PC 97 defines a system that is optimized for home recreation applications such as game playing, Internet browsing, personal communications, and educational multimedia CD-ROMs. Many features of Entertainment PC 97 are designed to ensure quick adoption of the advanced technologies required for new forms of digital entertainment and to provide the very best multimedia capabilities in every category when compared to all other competing platforms for game playing, education and entertainment, and Internet browsing.

However, it is recognized that there is a market category for lower-end PCs that support good quality output for entertainment and educational software applications that are graphics- and audio-intensive. Such systems have been commonly known as "multimedia PCs." This section summarizes the subsystem features of a Basic PC 97 system that is designed for this market.

55. "Multimedia PC" meets PC 97 minimum requirements

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | N/A

The following table summarizes the minimum requirements and recommendations for each subsystem.

Notice that for a multimedia PC that implements a recommended feature, the PC 97 requirements for that particular feature must be met. However, the system designer can implement recommended items on a feature-by-feature basis. That is, not all recommended features need to be implemented if one or more features are selected for a multimedia PC.

Multimedia PC Requirements and Recommendations

Required | Recommended | PC 97 reference
System requirements: Basic PC 97 minimum | Pentium-class 166 MHz MMX instruction set, or equivalent | "Basic PC 97"
System buses: Basic PC 97 minimum | IEEE 1397 No ISA add-on devices provided with PC | "USB"; "IEEE 1394"
I/O devices: Basic PC 97 minimum | USB game pad Devices use USB or IEEE 1394 bus Remote control | "Input Components"
Graphics components: Basic PC 97 minimum MPEG-1 graphics support | 64-bit accelerator Low resolution modes PC 97 recommendations or 2-D and 3-D acceleration 20" or larger monitor or NTSC/PAL TV output PC 97 DVD playback, if video discs are supported | "Graphics Adapters"; "Video Components"
Audio components: Basic PC 97 audio | Advanced PC 97 audio Devices use USB bus Support music synthesis | "Audio Components"
Communications: Internal 28.8 Kbps V.34 data/fax/voice modem | ISDN | "Modems"
Storage capabilities: 6x CD-ROM 1 GB hard disk | Bus mastering DVD-ROM Larger capacity hard disk | "Storage and Related Peripherals"


References for Basic PC 97

The following presents some of the references, services, and tools available to help build hardware that is optimized to work with Windows operating systems.

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm
Vendor ID registration: pnpid@microsoft.com

Microsoft Device Driver Kits (DDKs) for Windows operating systems

Microsoft Developer Network (MSDN) Professional membership

Advanced Configuration and Power Interface (ACPI) specification

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

Power management specifications for device and bus classes
Guidelines for audible noise and other OnNow technologies

http://www.microsoft.com/hwdev/onnow.htm

MultiProcessor Specification Version 1.4

Intel part number 242016-002
Phone: (800) 879-4683

El Torito — Bootable CD-ROM Format Specification Version 1.0
Compaq, Intel, Phoenix BIOS Boot Specification v. 1.01

http://www.ptltd.com/techs/specs.html

Intel/Duracell Smart Battery System Specification

http://www.intel.com/ial/powermgm/sbovr.htm


Checklist for Basic PC 97

Basic PC 97 Workstation PC 97 Entertainment PC 97


General System Requirements for Basic PC 97

1. Minimum CPU: Pentium-class 120 MHz or equivalent

120 MHz Required 166 MHz Required 166 MHz Required

2. L2 cache with 256K minimum, for Pentium-class processor

Recommended Required Required

3. Minimum system memory: 16 MB

Required 32 MB Required Required

4. Advanced Configuration and Power Interface (ACPI) support

Required Required Required

5. Hardware support for OnNow initiative

Required Required Required

6. BIOS support for OnNow initiative for x86-based systems

Required Required Required

7. System BIOS support for boot devices, for x86-based systems

Required Required Required

8. BIOS boot support for USB keyboard, if USB is the only keyboard

Required Required Required


Industrial Design Requirements for Basic PC 97

9. All expansion slots in the system are accessible for users to insert cards

Required Required Required

10. Audible noise meets PC 97 standards

Recommended Recommended Required

11. System and component design practices follow accessibility guidelines

Recommended Recommended Recommended


General Device Requirements for Basic PC 97

12. Each device and driver meets PC 97 device requirements

Required Required Required

13. Each bus complies with written specifications and PC 97 requirements

Required Required Required

14. Each bus and device complies with current Plug and Play specifications

Required Required Required

15. Unique Plug and Play device ID for each system device and add-on device

Required Required Required

16. Option ROMs meet Plug and Play requirements (for x86-based systems)

Required Required Required

17. "PNP" vendor code used only to define a legacy device's CompatibleID

Required Required Required

18. All devices support correct 16-bit decoding for I/O port addresses

Required Required Required

19. Devices and buses support hot plugging if using USB, 1394, or PC Card

Required Required Required

20. The user is protected from incorrectly connecting devices

Required Required Required

21. Minimal user interaction needed to install and configure devices

Required Required Required

22. Device driver and installation meet Windows and Windows NT standards

Required Required Required

23. Multifunction add-on devices meet general device requirements for each device

Required Required Required

24. Standard system board devices use ISA-compatible addresses

Required Required Required

Basic PC 97 Buses and Devices


System Buses for Basic PC 97

25. Universal Serial Bus with one USB port, minimum

Required Required Required, with 2 USB ports

26. Support for other high-speed expansion capabilities

Recommended | Recommended | IEEE 1394 Required
CardBus Required | for mobile |

27. If present, PCI bus meets PCI v. 2.1 and higher, plus PC 97 requirements

Required Required Required

28. ISA expansion bus

Optional Optional Optional


I/O Devices for Basic PC 97

29. Keyboard connection and keyboard

Required Required USB or wireless Required

30. Pointing device connection and pointing device

Required Required USB or wireless Required

31. Connection for external parallel devices

Required Required Required

32. Connection for external serial devices

Required Required Required

33. Wireless capabilities in PC system

Recommended Recommended Required

34. Support for installing the operating system

Required Required Required

35. Audio support in PC system meets PC 97 requirements

Recommended Recommended Advanced audio Required

36. Communications device provided with PC system

Recommended Required Required


Graphics Adapter and Monitor for Basic PC 97

37. Display adapter meets PC 97 minimum requirements

800x600x16 bpp | 1024x768x16 bpp | 1024x768x16 bpp
640x480x8 bpp, small LCD |  |

38. Support for NTSC or PAL TV output, if no large-screen monitor

Recommended Recommended Required

39. Color monitor supports DDC 2.0 Level B, EDID, and 800x600, minimum

Required Required Required

40. System supports MPEG-1 playback

Required Required Required

41. PC 97 DVD playback requirements, if PC system includes DVD-Video

Required with DVD-Video Required with DVD-Video Required


Storage and Related Peripherals for Basic PC 97

42. Support Int 13h Extensions in system and option ROMs

Required Required Required

43. Host controller for storage device meets PC 97 requirements, if present

Required Required Required

44. Primary host controller supports bus mastering

Recommended Required Required

45. Hard drive meets PC 97 requirements, if present

Required Required Required

46. Media status notification support for removable media

Required Required Required

47. Legacy floppy disk controller built into system

Optional Optional Optional


Mobile PC and Form-Factor Related Requirements

48. CardBus for high-speed expansion capabilities on mobile PCs

Required Required Required

Mobile PC Design Exceptions and Clarifications


Docking Station Requirements

49. Mobile unit and docking station meet PC 97 requirements as a pair

Required

50. Docking station meets ACPI requirements

Required

51. Docking station meets all Basic PC 97 requirements for general devices, expansion cards, system bus, and system board

Required

52. Automatic resource assignment and dynamic disable capabilities for mobile/docking station pair

Required

53. Fail-safe docking

Required


Port Replicator Requirements

54. Automatic resource assignment and dynamic disable capabilities for replacement devices

Required


Multimedia PC Guidelines for PC 97

55. "Multimedia PC" meets PC 97 minimum requirements

Required Required N/A


Chapter 4 Workstation PC 97

This chapter presents the requirements and recommendations for network workstations under the Microsoft Windows family of operating systems.


Overview for Workstation PC 97

This section presents the key design features for Workstation PC 97. PC 97 Hardware Design Guide provides the first definition of this PC category for the "Designed for Microsoft Windows" logo program.

Although the design requirements for Workstation PC 97 can support running either the Windows 95 or Windows NT operating system, these requirements are optimized to support complex Win32-based applications, which usually run on Windows NT Workstation, for users whose principal computing work involves using mission-critical networked applications, engineering or scientific applications, or media-authoring or software development tools. Although Windows NT Workstation is used on standalone systems, the PC 97 requirements support the more common use of Windows NT Workstation as a platform for network productivity.

These are the key design issues for Workstation PC 97:

  • PC 97 requirements for implementing the new Advanced Configuration and Power Interface (ACPI), new bus class and device class power management requirements, and implementing USB in the system.
  • Recommendations for input components and graphics adapter capabilities, based on the intended use of the workstation.

Important The system requirements defined in PC 97 Hardware Design Guide provide guidelines for designing PC systems that best run Windows 95 and Windows NT. These design requirements are not the basic system requirements for running the Windows operating system. Also, hardware features are described as Required, Recommended, or Optional for the "Designed for Microsoft Windows" logo program:

  • Required: These are the basic hardware features that must be implemented to qualify for the "Designed for Microsoft Windows" logo.

    Recommended: These features add functionality supported by the Windows operating systems. For "Designed for Microsoft Windows" logo testing, if a recommended feature is implemented, it must meet the standards for that feature as defined in this guide. Some recommended features might become requirements under the logo program in the future.

  • Optional: These features are neither required nor recommended, but if the feature is implemented in a PC 97 system, it must meet the specified requirements. These features will not become requirements under the logo program in the future.


System Requirements for Workstation PC 97

This section summarizes the requirements for the basic components of Workstation PC 97 systems.

1. Minimum microprocessor:
Pentium-class 166 MHz or equivalent, or RISC-based processor

Required

Recommended: two or more microprocessors.

The minimum microprocessor capability is required to support the demands of the complex computational and graphics-intensive software that will be used on a Workstation PC 97 system. The processor requirement for RISC-based systems is one of the following:

  • MIPS R4x00 or equivalent
  • Digital Alpha 21064 (EV4) or higher processors
  • IBM PowerPC Architecture for RISC-based systems

If multiprocessor support is provided in a Workstation PC 97 system with x86-based processors, such support must comply with MultiProcessor Specification Version 1.4 or higher (available from Intel). An ARC- or ACE-compliant RISC-based system meets the requirements for multiprocessor support. Notice, however, that dual processors will never become a logo requirement.

2. L2 cache with 256K minimum, for Pentium-class processor

Required

Recommended: 512K cache.

The minimum Level 2 cache is required for performance on x86-based Workstation PC 97 systems. This requirement does not apply for a Pentium Pro-class system with a built-in L2 cache.

If multiprocessor support is provided with Pentium-class processors, each processor must have a separate L2 cache.

3. Minimum system memory: 32 MB

Required

Recommended: 64 MB. For multiprocessor systems, 64 MB minimum is required.

At least 28 MB of system memory must be completely available for the system to use and cannot be locked from use by the operating system. For multiprocessor systems, at least 60 MB must be completely available for the system to use.

Note This minimum requirement for memory available to the operating system does not preclude applications that use dynamically allocated memory for audio or video playback or other temporary uses of system memory.

4. Workstation PC 97 meets Basic PC 97 general system requirements

Required

This includes the following specific requirements, as defined in the "Basic PC 97" chapter in this guide:

  • Advanced Configuration and Power Interface (ACPI) support
  • Hardware support for OnNow initiative
  • BIOS support for OnNow initiative (for x86-based systems only)
  • BIOS support for boot devices (for x86-based systems only)
  • BIOS boot support for USB keyboard (for x86-based systems with only USB keyboards)


Industrial Design Requirements for Workstation PC 97

This section summarizes the physical design requirements for Workstation PC 97 systems. These requirements are in addition to those related to the OnNow initiative for power-state indicators and easily accessible power switches.

5. All expansion slots in the system accessible for users to insert cards

Required

The expansion slots cannot be physically blocked by components or devices provided with the system. This does not exclude configurations that allow space for only half-height cards for some slots or passive back planes used for connectors, and so on.

6. Audible noise meets PC 97 standards

Recommended

A PC 97 system should be "silent" in the Sleeping state and as quiet as possible during active operations. Recommended test procedures and measurements will be documented by Microsoft.

The need to limit audible noise comes from the OnNow design initiative. A PC that uses OnNow technologies will be active even when not under direct operation by the user. These operations must happen silently so as not to interfere with other activities in the work site.

7. System and component design practices follow accessibility guidelines

Recommended

Accessibility design guidelines are provided in Appendix C, "Accessibility," in this guide. These guidelines were developed in consultation with the Trace Research and Development Center at the University of Wisconsin. Notice that this recommendation will not become a requirement.


General Device Requirements for Workstation PC 97

This section defines the general requirements for devices on a Workstation PC 97 system. The requirements in this section apply for every device, whether it is present included in the PC system or provided as an add-on device.

8. Workstation PC 97 meets Basic PC 97 general device requirements

Required

This includes the following specific requirements, as defined in the "Basic PC 97" chapter in this guide:

  • Each device and driver meets PC 97 device requirements
  • Each bus complies with written specifications and PC 97 requirements
  • Each bus and device complies with current Plug and Play specifications
  • Unique Plug and Play device ID for each system device and add-on device
  • Option ROMs meet Plug and Play requirements (for x86-based systems only)
  • "PNP" vendor code used only when defining a legacy device's CompatibleID
  • All devices support correct 16-bit decoding for I/O port addresses
  • Devices and buses support hot plugging if using USB, 1394, or PC Card
  • The user is protected from incorrectly connecting devices
  • Minimal user interaction needed to install and configure devices
  • Device driver and installation meet Windows and Windows NT standards
  • Multifunction add-on devices meet general device requirements for each device
  • Standard system board devices use ISA-compatible addresses


Buses and Devices for Workstation PC 97

This section defines specific requirements for buses and devices provided in a Workstation PC 97 system, in addition to the basic requirement for supporting the Advanced Configuration and Power Interface specification, as defined earlier in this chapter.


System Buses for Workstation PC 97

This section summarizes the general requirements for system buses. Additional requirements are defined in Part 3 of this guide for particular buses.

9. Universal Serial Bus, with one USB port, minimum

Required

Universal Serial Bus (USB) provides a bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, communications devices, and input devices on a single bus.

The USB implementation in the system must meet the requirements defined in USB specifications, plus any additional requirements for PC 97 defined in the "USB" chapter in Part 3 of this guide.

10. Support for other high-speed expansion capabilities

Recommended

Additional support for expansion capabilities can be provided using PCI v. 2.1, IEEE 1394, or CardBus, or other high-speed buses. Any expansion bus implemented in the system must meet the requirements defined in the related chapter in Part 3 of this guide.

11. If present, PCI bus meets PCI v. 2.1 and higher, plus PC 97 requirements

Required

If PCI is used, the PCI bus must meet the requirements defined in PCI v. 2.1 or higher, plus any additional requirements for PC 97 defined in the "PCI" chapter in Part 3 of this guide.

12. ISA expansion bus

Optional

If an ISA bus is implemented in a Workstation PC 97 system, all the requirements defined in the "ISA" chapter in Part 3 of this guide must be met.

Notice that including ISA in the system will probably require support for traditional keyboard, parallel, and serial ports. For requirements related to these devices, see the "Serial, Parallel, and Wireless Support" and "Input Components" chapters in Part 4 of this guide.

PC 97 requirements exclude using ISA as the bus for the graphics adapter. For Workstation PC 97, the network adapter is also excluded from using the ISA bus.


I/O Devices for Workstation PC 97

This section defines the general requirements for I/O devices. Additional requirements are defined in the sections titled "Graphics Adapter and Monitor for Workstation PC 97" and "Storage and Related Peripherals for Workstation PC 97" later in this chapter.

Tips for Selecting I/O Performance Components. For PC manufacturers who want to select high-performance components for Workstation 97 systems, these are design features to look for in I/O components:

  • Adapter supports bus mastering, especially for use with processors that have Pentium Pro-equivalent register sets.
  • PCI adapter properly supports higher-level PCI commands for intelligent data transfer.
  • Drivers are tuned for 32-bit performance.

13. Keyboard connection and keyboard

Required

Recommended: USB connection. The external connection requirements can also be met using a PS/2-style port or wireless capabilities in the system. For complete requirements for keyboard ports and peripherals, see the "Input Components" chapter in Part 4 of this guide.

14. Pointing device connection and pointing device

Required

Recommended: USB connection. The external connection requirements can also be met using a PS/2-style port or wireless capabilities in the system. For complete requirements for mouse ports and peripherals, see the "Input Components" chapter in Part 4 of this guide.

15. High-precision input device in addition to mouse

Recommended

Recommended: USB connection. For workstations that support engineering or CAD computing, a digitizer, drawing tablet, or other special pointing device is Recommended. Any pointing device included with the system must meet the PC 97 requirements for input devices.

16. Connection for external parallel devices

Required

Recommended: SCSI or external bus such as USB, IEEE 1394, or PC Card. This can also be provided as a parallel port with ECP mode capabilities. For complete requirements for parallel ports, see the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

17. Connection for external serial devices

Required

Recommended: USB or PC Card. This can also be provided as a 16550A serial port. For complete requirements for serial ports, see the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

18. Wireless capabilities in PC system

Recommended

If wireless capabilities are included in the system, PC 97 requirements must be met, as defined in the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

19. CD-ROM or network adapter support for installing the operating system

Required

For Workstation PC 97, a network adapter included with the system is strongly recommended.

The PC 97 system must include I/O device support to allow the user to install (or reinstall) the operating system. For the Windows NT operating system, either a CD-ROM drive or network adapter must be included in the system, because Windows NT does not support installing the operating system from a floppy disk drive.

  • CD-ROM drive: if this device is present, the host controller must meet requirements defined in the related chapters in Part 3 of this guide, and the device must meet the requirements defined in the "Storage and Related Peripherals" chapter in Part 4 of this guide.
  • Network adapter: if the network interface is implemented in the PC system (either on the system board or through an expansion card), the network adapter must meet the requirements defined in the "Network Communications" chapter in Part 4 of this guide. These requirements include support for an NDIS 4.0 miniport driver plus automatic detection of cable and transceiver type.

    An ISA-based network adapter solution is not allowed for a Workstation PC 97 system.

Note It is recognized that OEMs supply PC systems to corporations in situations where the customer will insert network adapters at the end-user site. Workstation systems designed for specific corporate customer features are exempt from this PC 97 requirement.

20. Audio support in PC system meets PC 97 requirements

Recommended

If audio is implemented in a PC 97 system, it must meet the minimum requirements defined in the "Audio Components" chapter in Part 4 of this guide.

21. Communications device provided with PC system

Required

The following device options can meet this requirement:

  • Modem. If modem capabilities are implemented in the PC system, the device must meet the requirements defined in the "Modems" chapter in Part 4 of this guide.
  • ISDN or cable modem for high-speed communications. High-speed communication capabilities are strongly recommended for Workstation PC 97. For information about requirements for ISDN and cable modems, see the "Network Communications" chapter in Part 4 of this guide.
  • Network adapter. Requirements for a network adapter are defined earlier in this section.
  • ATM adapter. If this adapter is included in a Workstation PC 97 system, it must meet the requirements defined in the "Network Communications" chapter in Part 4 of this guide.

Note It is recognized that OEMs supply PC systems to corporations in situations where the customer will insert network adapters at the end-user site or where the customer has particular feature demands. Workstation systems designed for specific corporate customers are exempt from this PC 97 requirement.


Graphics Components for Workstation PC 97

This section summarizes the Workstation PC 97 requirements for graphic components, including graphics adapter and monitor.

Tips for Selecting Performance Components for Graphics Subsystem.
For PC manufacturers who want to select high-performance components for Workstation 97 systems, these are design features to look for in graphics components:

  • Adapter supports bus mastering.
  • Adapter supports write combining (WC) memory type to allow speculative writers to linear frame buffer with processors that have Pentium Pro-equivalent register sets.
  • Driver sets up memory-type range registers using the Windows NT 4.0 range registers.
  • Drivers are tuned for 32-bit performance.
  • With Pentium Pro-class processors, 4 MB display RAM is highly recommended to support WC optimizations under Windows NT 4.0.

If the target use is the engineering desktop, the following should be considered:

  • Strong wire frame and shaded triangle performance in 2D hardware acceleration
  • Support for OpenGL acceleration
  • Support for 3D acceleration
  • Support for Parametrix Technologies Corporation (PTC), SDRC, and SoftImage

22. Display adapter meets PC 97 minimum requirements

Required

As defined in the "Basic PC 97" chapter in this guide, the graphics subsystem must include the following support:

  • Minimum resolution: 1024x768x16 bpp

    Recommended: 1280x1024x24 bpp

    For Workstation PC 97, the graphics-intensive requirements for many Win32-based productivity applications require a higher minimum resolution than that specified for Basic PC 97.

    Recommended: 4 MB display RAM

    For workstations with Pentium Pro-class processors or with intended uses such as engineering, CAD computing, or other graphics-intensive applications, the extra display RAM is strongly recommended.

  • Primary graphics adapter does not use legacy bus
  • System operates normally with default VGA mode driver
  • Support for multiple adapters and multiple monitors

Recommended: Support for NTSC or PAL TV output. (This will not become a requirement for Workstation PC 97.)

For complete details related to basic graphics adapter requirements, see the "Graphics Adapters" chapter in Part 4 of this guide.

23. Hardware acceleration for 2-D and 3-D graphics

Recommended

Various hardware acceleration features for 2-D and 3-D graphics can be implemented to improve overall graphics performance. For Workstation PC 97 systems that will support precise graphics applications, such as engineering or CAD software, graphics hardware 3-D acceleration should support OpenGL capabilities built into the Windows NT operating system. Microsoft DirectDraw and Direct3D are used by applications to accelerate graphics display by providing direct manipulation of video display memory, hardware blters, hardware overlays, and page flipping.

For information about required and recommended features if hardware acceleration is implemented for 2-D and 3-D graphics, see the "Graphics Adapters" chapter in Part 4 of this guide.

24. Color monitor supports DDC 2.0 Level B and 800x600, minimum

Required

If a monitor is provided with a Workstation PC 97 system, it must meet the minimum capabilities defined for PC 97. For complete PC 97 requirements for monitors, see the "Video Components" chapter in Part 4 of this guide.

25. System supports MPEG-1 playback

Required

Microsoft provides operating system support through Microsoft ActiveMovie. For information about performance and graphics hardware requirements to support video playback, see the "Video Components" chapter in Part 4 of this guide.


Storage and Related Peripherals for Workstation PC 97

This section summarizes the requirements for storage devices for Workstation PC 97. For system requirements related to CD-ROM, see the "System Buses and I/O Devices for Workstation PC 97" section earlier in this chapter.

Tips for Selecting Performance Components for Storage. For PC manufacturers who want to select high-performance components for Workstation 97 systems, these are design features to look for in storage components:

  • Controller supports bus mastering (a Workstation PC 97 requirement).
  • Disks support reduced latency and fast rotational speeds.
  • Disks support at least 2:1 memory interleaving when SDRAM is not used.
  • Drivers are tuned for 32-bit performance.

26. Host controller for storage device meets PC 97 requirements

Required

Recommended to support multiple storage devices: SCSI host controller.

The host controller must meet requirements defined for the bus it uses; for SCSI or IDE controllers, it must also meet the requirements in the "ATA and ATAPI" or "SCSI" chapter in Part 3 of this guide.

27. Primary host controller supports bus mastering

Required

For Workstation PC 97, the primary host controller must support bus mastering, whether using IEEE 1394, IDE, or SCSI.

28. Workstation PC 97 meets storage requirements defined for Basic PC 97

Required

This includes the following specific requirements, as defined in the "Basic PC 97" chapter in this guide:

  • Support Int 13h Extensions in system and option ROMs (for x86-based systems only)
  • Hard disk drive meets requirements defined in the "Storage and Related Peripherals" chapter in Part 4 of this guide
  • Media status notification support for removable media

29. DVD-ROM drive

Recommended

  • Any DVD device included in a Workstation PC 97 system must meet the requirements defined for DVD in the "Storage and Related Peripherals" chapter in Part 4 of this guide.

    Note If a Workstation PC 97 system includes DVD-Video support, the PC must also provide PC 97 playback support for DVD content, as defined in the "Video Components" chapter in Part 4 of this guide.


References for Workstation PC 97

The following presents some of the references, services, and tools available to help build hardware that is optimized to work with Windows operating systems.

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Microsoft Device Driver Kits (DDKs) for Windows operating systems

Microsoft Developer Network (MSDN) Professional membership

Advanced Configuration and Power Interface (ACPI) specification

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

Power Management specifications for device and bus classes Guidelines for audible noise and other OnNow technologies

http://www.microsoft.com/hwdev/onnow.htm

MultiProcessor Specification Version 1.4

Intel part number 242016-002
Phone: (800) 879-4683


Checklist for Workstation PC 97


System Requirements for Workstation PC 97

1. Minimum microprocessor: Pentium-class 166 MHz or equivalent, or RISC-based processor

Required

2. L2 cache with 256K minimum, for Pentium-class processor

Required

3. Minimum system memory: 32 MB

Required

4. Workstation PC 97 meets Basic PC 97 general system requirements

Required


Industrial Design Requirements for Workstation PC 97

5. All expansion slots in the system accessible for users to insert cards

Required

6. Audible noise meets PC 97 standards

Recommended

7. System and component design practices follow accessibility guidelines

Recommended


General Device Requirements for Workstation PC 97

8. Workstation PC 97 meets Basic PC 97 general device requirements

Required


Buses and Devices for Workstation PC 97

System Buses for Workstation PC 97

9. Universal Serial Bus, with one USB port, minimum

Required

10. Support for other high-speed expansion capabilities

Recommended

11. If present, PCI bus meets PCI v. 2.1 and higher, plus PC 97 requirements

Required

12. ISA expansion bus

Optional

I/O Devices for Workstation PC 97

13. Keyboard connection and keyboard

Required

14. Pointing device connection and pointing device

Required

15. High-precision input device in addition to mouse

Recommended

16. Connection for external parallel devices

Required

17. Connection for external serial devices

Required

18. Wireless capabilities in PC system

Recommended

19. CD-ROM or network adapter support for installing the operating system

Required

20. Audio support in PC system meets PC 97 requirements

Recommended

21. Communications device provided with PC system

Required

Graphics Components for Workstation PC 97

22. Display adapter meets PC 97 minimum requirements

Required

23. Hardware acceleration for 2-D and 3-D graphics

Recommended

24. Color monitor supports DDC 2.0 Level B and 800x600, minimum

Required

25. System supports MPEG-1 playback

Required

Storage and Related Peripherals for Workstation PC 97

26. Host controller for storage device meets PC 97 requirements

Required

27. Primary host controller supports bus mastering

Required

28. Workstation PC 97 meets storage requirements defined for Basic PC 97

Required

29. DVD-ROM drive

Recommended


Chapter 5 Entertainment PC 97

This chapter presents the requirements and recommendations for entertainment PCs under the Microsoft Windows family of operating systems.


Overview for Entertainment PC 97

This section presents the key design features for Entertainment PC 97 under Microsoft Windows.

PC 97 Hardware Design Guide provides the first definition of this PC category for the "Designed for Microsoft Windows" logo program. Notice that the Entertainment PC 97 system is not an expanded definition for the category of so-called "multimedia PCs." To identify the requirements for such a multimedia PC, see the "Basic PC 97" chapter, and also study the recommendations for audio and graphics subsystem components in Part 4 of this guide.

Entertainment PC 97 is an enhanced set of design guidelines for Windows-based PCs, based on a superset of the Basic PC 97 guidelines. For example, the graphics and audio subsystems for Entertainment PC 97 are designed to optimize the capabilities of software applications that use Microsoft ActiveX and DirectX interfaces.

The overall goal for the Entertainment PC is to expand the PC market by providing a PC system tailored for high-quality entertainment and communications capabilities with ease-of-use features that will help overcome barriers to adoption for new users. An Entertainment PC 97 system is optimized for the following uses:

  • Games – the best titles, with the most complex, realistic graphics and audio.
  • Education – the most engaging titles, with full-screen video, interactive animation, and so on.
  • Active Internet – enhanced web communications capabilities, with personalized and animated web sites, chat rooms, and so on.
  • Personal communications – multimedia e-mail, Internet audio phone, video phone, and so on.
  • Interactive, high-resolution TV and movie viewing – higher video quality, real-time links to content producers, and so on.
  • Connection with traditional consumer electronics devices – home theater surround audio for games and DVD movies (for example, Dolby AC-3); fast and easy capture, editing, and playback of personal video.

These are the key design issues for Entertainment PC 97:

  • Combining high-performance 2-D and 3-D graphics subsystem designed for the best games with better-than-television quality, full-screen, MPEG-2 motion video to deliver DVD movies, cable and digital satellite television, and so on.
  • Enabling connection to large-screen displays, including standard televisions, for much more a realistic graphics experience than smaller desktop monitors can provide.
  • Implementing a high-fidelity audio subsystem on par with consumer stereo systems, able to deliver rich content such as games with positional 3-D audio, professionally mastered music CDs, and so on.
  • Enabling PC connections via USB and IEEE 1394 to consumer electronic devices such as camcorders, VCRs, and home theater stereo systems.
  • Providing home appliance usability for ease of use.
  • Extending human input device support with remote control, game input controls, and other devices that use USB, IEEE 1394, and other external connections.

Microsoft expects OEMs will build PCs that conform to the Entertainment PC 97 guidelines in the traditional desktop multimedia PC form factor. So-called "living room" PCs that attach to televisions or large-screen VGA monitors are an additional opportunity for market expansion by OEMs. Microsoft supports and encourages investment in the living-room form factor as part of its SIPC initiative, and this chapter provides additional design notes and recommendations for living-room PC design. However, requirements such as the "sealed case," graphics capabilities related to TV output, advanced audio capabilities, and other items apply for Entertainment PCs based on any form factor, including mobile PCs.

Important The system requirements defined in PC 97 Hardware Design Guide provide guidelines for designing PC systems that best run Windows 95 and Windows NT. These design requirements are not the basic system requirements for running the Windows operating system. Also, hardware features are described as Required, Recommended, or Optional for the "Designed for Microsoft Windows" logo program:

  • Required: These basic hardware features must be implemented to qualify for the "Designed for Microsoft Windows" logo.
  • Recommended: These features add functionality supported by the Windows operating systems. For "Designed for Microsoft Windows" logo testing, if a recommended feature is implemented, it must meet the standards for that feature as defined in this guide. Some recommended features might become requirements under the logo program in the future.
  • Optional: These features are neither required nor recommended, but if the feature is implemented in a PC 97 system, it must meet the specified requirements. These features will not become requirements under the logo program in the future.


System Requirements for Entertainment PC 97

This section summarizes the requirements for the basic components of Entertainment PC 97 systems.

1. Minimum CPU: Pentium-class 166 MHz or equivalent

Required

This minimum computational capability is required to support the demands of the complex graphics- and media-intensive software and video titles that will be used on an Entertainment PC 97 system.

2. L2 cache with 256K minimum, for Pentium-class processor

Required

This minimum Level 2 cache is required for performance on Entertainment PC 97 systems. This requirement does not apply for a Pentium Pro-class system with a built-in L2 cache.

3. Entertainment PC 97 meets Basic PC 97 general system requirements

Required

This includes the following specific requirements, as defined in the "Basic PC 97" chapter in this guide:

  • Minimum system memory: 16 MB
  • Advanced Configuration and Power Interface (ACPI) support
  • Hardware support for OnNow initiative
  • BIOS support for OnNow initiative (for x86-based systems only)
  • BIOS support for boot devices (for x86-based systems only)
  • BIOS boot support for USB keyboard (for x86-based systems with only USB keyboards)


Industrial Design Requirements for Entertainment PC 97

This section summarizes the physical design requirements for Entertainment PC 97 systems. These requirements are in addition to those related to the OnNow initiative for power-state indicators and easily accessible power switches.

4. All expansion slots in the system accessible for users to insert cards

Required

The expansion slots cannot be physically blocked by components or devices provided with the system. This does not exclude configurations that allow space for only half-height cards for some slots or passive back planes used for connectors, and so on. (This requirement applies only if the system does not implement a "sealed case" design as described later in this section.)

5. Audible noise meets PC 97 standards

Required

An Entertainment PC 97 system must be "silent" in the Sleeping state and must also be quiet during active operations, including hard-disk seek activities.

Recommended test procedures and measurements will be documented by Microsoft.

The need to limit audible noise comes from the OnNow design initiative. A PC that uses OnNow technologies will be active even when not under direct operation by the user. For example, entertainment PCs are likely to perform scheduled and background tasks such as receiving faxes and voice mail, checking e-mail, and downloading TV program guide information and Internet web pages using a digital satellite connection or modem. These operations must happen silently so as not to interfere with other activities in the home.

6. "Sealed case" design with external expansion for all components

Recommended

The entire PC case can be "sealed," with no user-serviceable parts inside. It is recognized that computers will continue to need service and that literally sealing the case would prohibit servicing the PC. The term "sealed case" refers to a PC system designed with the assumption that the user will never need to open the case. All expansion capabilities should be made available using options such as USB or IEEE 1394, with support for removable devices provided using PC Card or other design options to allow adding more storage or other devices.

Modular designs can be used to support RAM and CPU upgrades; however, such designs are not required as part of the "sealed case" recommendation.

This recommendation is intended to make the PC more usable and accessible for end users by ensuring that system components can be upgraded or added without using a screwdriver or other special tools. For more information about the "sealed case" concept, see "PC 97 Design Issues" in Part 1 of this guide.


General Device Requirements for Entertainment PC 97

This section defines the general requirements for devices on an Entertainment PC 97 system. The requirements in this section apply for every device, whether it is included in the PC system or provided as an add-on device.

7. Entertainment PC 97 meets Basic PC 97 general device requirements

Required

This includes the following specific requirements, as defined in the "Basic PC 97" chapter in this guide:

  • Each device and driver meets PC 97 device requirements
  • Each bus complies with written specifications and PC 97 requirements
  • Each bus and device complies with current Plug and Play specifications
  • Unique Plug and Play device ID for each system device and add-on device
  • Option ROMs meet Plug and Play requirements (for x86-based systems only)
  • "PNP" vendor code used only to define a legacy device's CompatibleID
  • All devices support correct 16-bit decoding for I/O port addresses
  • Devices and buses support hot plugging if using USB, IEEE 1394, or PC Card
  • The user is protected from incorrectly connecting devices
  • Minimal user interaction needed to install and configure devices
  • Device driver and installation meet Windows and Windows NT standards
  • Multifunction add-on devices meet general device requirements for each device
  • Standard system board devices use ISA-compatible addresses


Buses and Devices for Entertainment PC 97

This section defines specific requirements for buses and devices provided in an Entertainment PC 97 system, in addition to the basic requirement for supporting Advanced Configuration and Power Interface (ACPI), as defined earlier in this chapter.


System Buses for Entertainment PC 97

This section summarizes the general requirements for system buses. Additional requirements are defined in Part 3 of this guide for particular buses.

8. USB, with two easily accessible connectors

Required

Universal Serial Bus (USB) provides a bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, communications devices, and input devices on a single bus.

To ensure that it is as easy as possible for end users to add and remove devices, expansion capabilities must be provided by including USB in the PC system. The Entertainment PC 97 system must include two USB ports. At least one USB connector must be in an easily accessible location (not on the rear panel) to support connection of auxiliary input devices such as game pads, joysticks, and trackballs. The recommended location for an easily accessible connector is to place the port on the front of the PC system. It is also recommended that at least one USB connector be placed on the rear panel.

The USB must meet the requirements defined in USB specifications, plus any additional requirements for PC 97 defined in the "USB" chapter in Part 3 of this guide.

9. IEEE 1394 with easily accessible connector

Required

Recommended: 2 connectors. At least one 1394 port is required on the Entertainment PC 97 system to connect 1394-based camcorders and other digital consumer electronics. To be easily accessible, the connection must not be on the rear panel. The recommended location is to place a port on the front of the PC system. If a second port is included, this connector can be placed on the rear for static connections to devices such as home stereos. For information about PC 97 requirements for this bus, see the "IEEE 1394" chapter in Part 3 of this guide.

10. Support for other high-speed expansion capabilities

Recommended

Support for additional expansion capabilities can be provided using PCI v. 2.1, CardBus, or other high-speed expansion bus. Any expansion bus implemented in the system must meet the requirements defined in the related chapter in Part 3 of this guide.

Note For Entertainment PC 97, IEEE 1394 is required to support most high-speed expansion capabilities. PCI and ISA are not recommended buses for providing expansion capabilities, because such buses do not allow end users to easily add and remove devices without screwdrivers.

11. If present, PCI bus meets PCI v. 2.1 and higher, plus PC 97 requirements

Required

If PCI is used, the PCI bus must meet the requirements defined in PCI v. 2.1 or higher, plus any additional requirements for PC 97 defined in the "PCI" chapter in Part 3 of this guide.


I/O Devices for Entertainment PC 97

This section defines the general requirements for I/O devices. Additional requirements are defined in the sections titled "Graphics Adapter and Monitor for Entertainment PC 97" and "Storage and Related Peripherals for Entertainment PC 97" later in this chapter.

12. Keyboard connection and keyboard

Required

Recommended: USB or wireless connection.

In addition to recommended implementations, a PS/2-style port can be included. For complete requirements for keyboard ports and peripherals, see the "Input Components" chapter in Part 4 of this guide.

Note For living-room PC design, a wireless connection is strongly recommended.

13. Pointing device connection and pointing device

Required

Recommended: USB or wireless connection.

In addition to the recommended implementations, a PS/2-style port can also be included, but is not the recommended solution for Entertainment PC 97. For complete requirements for mouse ports and peripherals, see the "Input Components" chapter in Part 4 of this guide.

Note For living-room PC design, this requirement can be satisfied by using a remote control pointing device, or by using a wireless keyboard that includes a connector to enable a standard mouse to be attached. The ability for users to attach a standard two-button mouse is strongly encouraged, although the device itself does not need to be included with the PC.

14. USB game pad or joystick

Required

This device must support the USB Human Input Device class specification and its driver must support Microsoft DirectInput. For more information about requirements for USB peripherals, see the "USB" chapter in Part 3 of this guide. For more information about the requirements for input devices, see the "Input Components" chapter in Part 4 of this guide.

Note For living-room PC design, a wireless connection is strongly recommended to allow greater freedom of movement and location for game players.

15. Remote control pointing device

Recommended

To enhance the appliance experience, especially on PCs designed for use in the living room, a wireless (infrared or radio-frequency) remote-control pointing device should be included with Entertainment PC systems. The device must provide at least the following functions and buttons:

  • Mouse pointer control with primary and secondary buttons (for example, trackball or mini-thumbstick)
  • PC Suspend and Resume (1 button; recommended label is "On/Off" or "Power")
  • Volume control (up/down) and mute

Some optional controls that might be included are the following:

  • TV channel and radio station control (up/down)
  • Number keys equivalent to numeric keypad of the PC keyboard
  • Windows Logo key
  • Recall previous channel
  • Function selection (TV, radio, CD)

16. All pointing devices work simultaneously

Required

All pointing devices implemented in the system must have drivers that support Microsoft DirectInput. All pointing devices must also be able to provide input correctly at the same time. This means that the pointing devices must not use competing protocols and that no pointing device is automatically disabled when another pointing device is in use. This also applies to game input devices, in order to enable multi-player gaming.

For more information, see the "Input Components" and "Serial, Parallel, and Wireless Support" chapters in Part 4 of this guide.

17. Legacy serial and parallel ports meet PC 97 requirements, if present

Required

Any standard parallel or serial ports included in the Entertainment PC 97 system must meet the requirements defined in the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

18. Support for installing the operating system

Required

For Entertainment PC 97, this requirement is met using the required DVD device, as described later in this chapter.

19. Audio support meets PC 97 Advanced audio requirements

Required

The PC 97 Advanced audio requirements are defined in the "Audio Components" chapter in Part 4 of this guide. This includes requirements for audio hardware capabilities and quality, plus external connections.

Note Audio is a key differentiating feature of Entertainment PC 97 designs vs. Basic PC 97 designs. Audio fidelity and functions must be significantly better — that is, on par with consumer electronics stereos. Positional 3-D audio and connection to home theater systems using IEEE 1394 enable more realistic game and video experiences. One opportunity for achieving this is to implement the audio subsystem as an external digital-to-analog converter attached to a secondary IEEE 1394 port on the rear of the PC. This isolates the analog audio stream from the RF noise of internal PC components while enabling easy connection to either legacy analog or new Plug and Play-compatible digital stereo components.

20. Data/fax/voice modem capabilities, 28.8 Kbps minimum

Required

Recommended: ISDN or cable modem for high-speed communications. For information about requirements for ISDN and cable modems, see the "Network Communications" chapter in Part 4 of this guide. For more information about modem requirements, see the "Modems" chapter in Part 4 of this guide.

For the Entertainment PC 97 system, the modem must have telephone answering machine features compatible with Unimodem/V. The modem must also have the following feature:

  • TIA-695 (AT+V); Speakerphone

The following voice and adaptive connection technologies are recommended:

  • Adaptive connection support, V.25, V.8, and V.8bis call control signaling, with V.25ter Annex A modem commands
  • Simultaneous voice/data integration capabilities

For a USB modem, the device must meet the related USB device class specifications. For information, see the "USB" chapter in Part 3 of this guide.

A system with a POTS-based video conferencing solution must supply an
H.324 – compatible modem. ISDN-based video conferencing solutions should be H.320 – compatible.

21. Digital broadcast satellite subsystem

Optional

If this capability is included in the Entertainment PC 97, the implementation must include a digital broadcast satellite network card, SMART card, and drivers for the Windows operating system, in compliance with the Microsoft Broadcast PC specification.


Graphics Components for Entertainment PC 97

This section summarizes the Entertainment PC 97 requirements for graphic components, including graphics adapter, monitor, video capture, TV output, and DVD playback support in hardware.

22. Display adapter meets PC 97 minimum requirements

Required

As defined in the "Basic PC 97" chapter in this guide, the graphics subsystem must include the following support:

  • Minimum resolution: 1024x768x16 bpp

Recommended: 1280x1024x24 bpp

For Entertainment PC 97, the graphics-intensive requirements for many applications require a higher minimum resolution than specified for Basic PC 97.

  • Primary graphics adapter does not use legacy bus
  • System operates normally with default VGA mode driver
  • Support for multiple adapters and multiple monitors

For complete details related to basic graphics adapter requirements, see the "Graphics Adapters" chapter in Part 4 of this guide.

23. Hardware acceleration for 2-D and 3-D graphics

Required

Microsoft DirectDraw and Direct3D are used by applications to accelerate graphics display by providing direct manipulation of video display memory, hardware blters, hardware overlays, and page flipping. Various hardware acceleration features for 2-D and 3-D graphics can be implemented to improve overall graphics performance.

For information about required and recommended hardware features for 2-D and 3-D acceleration, see the "Graphics Adapters" chapter in Part 4 of this guide.

24. Support for NTSC or PAL TV output, if no large-screen monitor

Required

This is required unless the system is bundled with a large-screen VGA monitor. For Entertainment PC 97, the ability to connect to a TV is key to its ability to delivering more realistic, large-screen TV, movie, and game viewing experiences. This capability must meet the PC 97 requirements for TV output for composite and S-Video connectors, parameter control, and hardware filtering and scaling capabilities. For more information, see the "Graphics Adapters" chapter in Part 4 of this guide.

25. Cable TV tuner

Recommended

The support provided with cable TV tuner capabilities should include electronic program guide (EPG) software.

If included in the Entertainment PC system, the NTSC/PAL decode component of the TV tuner and analog video input subsystems must properly support extraction of data transmitted during the vertical blanking interval (VBI). This includes allowing certain scan lines to be placed within a separate memory buffer.

26. System supports MPEG-1 playback

Required

Microsoft provides operating system support through Microsoft ActiveMovie. For information about performance and graphics hardware requirements to support video playback, see the "Video Components" chapter in Part 4 of this guide.

27. PC 97 DVD playback requirements

Required

DVD-Video support is required for Entertainment PC 97, and DVD playback capabilities must meet the requirements defined in the "Video Components" chapter in Part 4 of this guide. This requirement is in addition to the DVD-ROM requirements defined in the following section, "Storage and Related Peripherals for Entertainment PC 97."

28. Video input and capture

Recommended

An analog composite video input connector is recommended. The connector should be easily accessible on the Entertainment PC 97 system (that is, not on the rear panel). If this feature is implemented on the Entertainment PC 97 system, device support for video capture capabilities must meet the requirements defined in the "Video Components" chapter in Part 4 of this guide.

29. Large-screen DDC2B color entertainment monitor

Recommended

Support for NTSC/PAL TV output is required if the system does not include a large-screen VGA monitor. Games, movies, and other entertainment software experiences are greatly enhanced by display screens comparable to modern TV sizes, for example, 27 inches and above in the U.S. An Entertainment PC 97 system that includes a large-screen monitor must meet the requirements for entertainment monitors defined in the "Video Components" chapter in Part 4 of this guide.


Storage and Related Peripherals for Entertainment PC 97

This section summarizes the requirements for storage devices for Entertainment PC 97. For system requirements related to CD-ROM, see "System Buses and I/O Devices for Entertainment PC 97" earlier in this chapter.

30. System meets PC 97 storage requirements

Required

This includes the following specific requirements, as defined in the "Basic PC 97" chapter in this guide:

  • Support Int 13h Extensions in system and option ROMs (for x86-based systems only)
  • Host controller meets requirements defined for IEEE 1394, IDE, or SCSI in Part 3 of this guide
  • Hard disk drive meets requirements defined in the "Storage and Related Peripherals" chapter in Part 4 of this guide
  • Media status notification support for removable media

31. Primary host controller supports bus mastering

Required

The primary host controller must support bus mastering, whether using IEEE 1394, IDE, or SCSI.

32. DVD-ROM drive

Required

  • The DVD-ROM device included in an Entertainment PC 97 system must meet the requirements defined for DVD in the "Storage and Related Peripherals" chapter in Part 4 of this guide.
  • An Entertainment PC 97 system must also provide playback support for DVD content, as defined in the "Video Components" chapter in Part 4 of this guide.


References for Entertainment PC 97

The following table presents some of the references, services, and tools available to help build hardware that is compliant with Windows operating systems.

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Microsoft Device Driver Kits (DDKs) for Windows operating systems

Microsoft Developer Network (MSDN) Professional membership

Advanced Configuration and Power Interface (ACPI) specification

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

Power management specifications for device and bus classes
Guidelines for audible noise and other OnNow technologies

http://www.microsoft.com/hwdev/onnow.htm


Checklist for Entertainment PC 97


System Requirements for Entertainment PC 97

1. Minimum CPU: Pentium-class 166 MHz or equivalent

Required

2. L2 cache with 256K minimum, for Pentium-class processor

Required

3. Entertainment PC 97 meets Basic PC 97 general system requirements

Required


Industrial Design Requirements for Entertainment PC 97

4. All expansion slots in the system accessible for users to insert cards

Required

5. Audible noise meets PC 97 standards

Required

6. "Sealed case" design with external expansion for all components

Recommended


General Device Requirements for Entertainment PC 97

7. Entertainment PC 97 meets Basic PC 97 general device requirements

Required


Buses and Devices for Entertainment PC 97

System Buses for Entertainment PC 97

8. USB, with two easily accessible connectors

Required

9. IEEE 1394 with easily accessible connector

Required

10. Support for other high-speed expansion capabilities

Recommended

11. If present, PCI bus meets PCI v. 2.1 and higher, plus PC 97 requirements

Required

I/O Devices for Entertainment PC 97

12. Keyboard connection and keyboard

Required

13. Pointing device connection and pointing device

Required

14. USB game pad or joystick

Required

15. Remote control pointing device

Recommended

16. All pointing devices work simultaneously

Required

17. Legacy serial and parallel ports meet PC 97 requirements, if present

Required

18. Support for installing the operating system

Required

19. Audio support meets PC 97 Advanced audio requirements

Required

20. Data/fax/voice modem capabilities, 28.8 Kbps minimum

Required

21. Digital broadcast satellite subsystem

Optional

Graphics Components for Entertainment PC 97

22. Display adapter meets PC 97 minimum requirements

Required

23. Hardware acceleration for 2-D and 3-D graphics

Required

24. Support for NTSC or PAL TV output, if no large-screen monitor

Required

25. Cable TV tuner

Recommended

26. System supports MPEG-1 playback

Required

27. PC 97 DVD playback requirements

Required

28. Video input and capture

Recommended

29. Large-screen DDC2B color entertainment monitor

Recommended

Storage and Related Peripherals for Entertainment PC 97

30. System meets PC 97 storage requirements

Required

31. Primary host controller supports bus mastering

Required

32. DVD-ROM drive

Required


Chapter 6 USB

This chapter presents the requirements and recommendations for Universal Serial Bus (USB) under the Microsoft Windows family of operating systems.


Overview for USB

Universal Serial Bus (USB) provides a bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, serial and parallel ports, and scanners on a single bus.

For PC 97, USB provides a fast, low-cost solution that is strongly recommended for communications and input devices. The following are the key design features for USB under the Microsoft Windows operating systems:

  • For PC 97, USB is required on all systems that receive the "Designed for Microsoft Windows" logo.
  • All USB components in a PC 97 system must comply with the USB Specification and related USB device class specifications.
  • The host controller must comply with OpenHCI or UHCI.
  • Microsoft provides support for USB using the Microsoft Win32 Driver Model (WDM). Hardware vendors who implement USB solutions for devices can use the drivers provided by Microsoft or can create minidrivers to exploit any additional unique hardware features.


USB Basic Requirements

This section summarizes the basic design requirements for USB.

1. USB included on PC system

Required

This is required for all PC 97 system types. As noted in "Basic PC 97" in Part 2 of this guide, BIOS boot support is required when a USB keyboard is the sole keyboard support provided with the PC system.

2. All USB hardware complies with Universal Serial Bus Specification

Required

All USB hardware must comply with the USB Specification v. 1.0 or higher, as published by Compaq, Digital Equipment, IBM, Intel, Microsoft, NEC, and Nortel. This ensures that USB hardware has complete Plug and Play capabilities and is implemented in a standard way. For example, on any system that has USB capabilities, a user must be able to dynamically attach any USB peripheral to any USB connector; the operating system should recognize it automatically, load and initialize the appropriate drivers, and make the device available for use.

3. USB connectors use USB icon

Required

The icon can be molded, printed, or use permanent stickers (which can include text). Icons can be based on vendor designs or use the recommended icon for USB defined in the USB Specification, Chapter 6, as follows:

The USB icon should be molded into the connector and also placed on the product for ease of identifying the USB port. It is recommended that the icon on the product and the one on the plug be adjacent to each other when the plug and receptacle are mated. This icon can be used for both series A and B connector schemes. On the plug, there should be a .635 mm rectangular recessed area around the icon such that there is a perceptible feel of the icon.


USB Controller Requirements

This section summarizes USB class specifications and standards for host controllers.

4. USB host controller complies with OpenHCI or UHCI

Required

The host controller must be compliant with either OpenHCI for USB (published by Compaq, Microsoft, and National Semiconductor) or Universal HCI (UHCI; published by Intel).

Microsoft intends to support only these two USB host controller implementation standards. Hardware manufacturers who design to one of these specifications should not require an additional device driver for their host controller.


Power Management for USB

This section summarizes the specific power management requirements for USB.

5. Compliance with USB power management requirements

Required

The Universal Serial Bus specification defines power management requirements for USB devices in the "Device Framework" section in the USB Specification v.1.0 or higher. The chapter defines specific requirements for power states that must be supported by USB devices (USBOn, USBSuspend, and USBOff, with power consumption levels for each) and capabilities (such as the saving of device state and the ability to signal a resume on the bus).

These requirements are mandatory for all USB devices per the USB Specification, and are required for PC 97.

6. Devices comply with "Power Device Class Specification" for USB

Required

All USB devices must implement the Power Device Class-specific descriptors and requests as described in the "Power Device Class Specification." In addition:

  • Any device that uses a power source other than the USB bus itself must also implement the Power Device Notification interrupt. These requirements ensure that Windows is able to control the device's power state, determine the status of the power source for the device (either bus, AC, or battery), and be notified when that status changes.
  • Each device must meet the related "Device Class Power Management Reference Specification" for its particular device class, as described in the related chapters in Part 4 of this guide.


Design Features for USB Peripherals

This section summarizes requirements related to bus-class specifications and standards for peripherals that use this bus.

7. Device complies with related USB device class specification

Required

If you develop a peripheral that fits into one of the USB device class definitions, it must comply with the related USB specification. This allows Microsoft to develop USB class drivers that support all compliant peripherals in that class. This requirement also means that you do not have to develop your own device drivers for Windows.


References for USB

This section lists some of the publications, services, and tools available to help build hardware supported by with Windows operating systems.

USB Specification v. 1.0 or higher
USB Device Class Specifications 1.0 or higher

USB-IF Information
Phone: (800) 433-3652 (U.S. $35)
http://www.teleport.com/~usb/ (free)

Open Host Controller Interface (OpenHCI) v. 1.0 or higher

http://www.microsoft.com/hwdev/specs/busspecs.htm

Universal HCI (UHCI) Design Guide for USB

http://www.intel.com/pc-supp/


Checklist for USB


USB Basic Requirements

1. USB included on PC system

Required

2. All USB hardware complies with Universal Serial Bus Specification

Required

3. USB connectors use USB icon

Required


USB Controller Requirements

4. USB host controller complies with OpenHCI or UHCI

Required


Power Management for USB

5. Compliance with USB power management requirements

Required

6. Devices comply with "Power Device Class Specification" for USB

Required


Design Features for USB Peripherals

7. Device complies with related USB device class specification

Required


Chapter 7 IEEE 1394

This chapter presents the requirements and recommendations for IEEE 1394 under the Microsoft Windows family of operating systems.


Overview for IEEE 1394

This section summarizes the basic design requirements for the approved IEEE 1394 – 1995 standard. The IEEE 1394 high-speed serial bus provides enhanced PC connectivity for a wide range of devices, from consumer audio/video (A/V) components to traditional PC storage devices including PCs and hand held devices.

IEEE 1394 has been widely adopted by the consumer electronics industry and provides a low cost, Plug and Play-compatible expansion interface for the PC. Although the 400 megabit per second (Mb/s) transfer rate for IEEE 1394 is well suited to multi-streaming I/O demands, a proposal for 800 Mb/s is in development.

The following summarizes the IEEE 1394 design issues related to Windows, as addressed in this chapter.

  • Compliance with approved IEEE 1394 – 1995 standards.
  • Plug and Play support for device configuration, device Command and Status Registers (CSRs), connectors and cabling, and connection fault handling.
  • Cable power distribution, including requirements for source devices and sink devices, self-powered devices, plus configuration ROM entries and CSRs.
  • Device power management, including CSRs and soft power protocols.
  • Device command protocols for Audio, Imaging, and Storage device classes.
  • Support for the Open Host Controller Interface (OpenHCI) for IEEE 1394. This provides a common device programming model with a script-based control interface and low interrupt count.


IEEE 1394 Basic Requirements

This section summarizes the basic design requirements for IEEE 1394, including specifications and standards.

1. Devices and controllers support IEEE 1394 standards

Required

Designs that interface to the IEEE 1394 high-speed bus must support the following industry standards and supplemental specifications:

  • IEEE 1394 – 1995
  • All devices must comply with the bus architecture and hardware interface specifications specified by the defining standard for the IEEE 1394 high-speed serial bus.
  • IEEE 1212 – 1991 Control Status Register Format (ISO/IEC 13213: 1994)
  • To ensure interoperability, all devices must comply with IEEE 1212 memory-mapped control and status register specifications as supplemented by the "1394 Plug and Play Design Reference" (described later in this chapter).

2. Controllers comply with OpenHCI for IEEE 1394

Required

The Open Host Controller Interface (OpenHCI) for IEEE 1394 specifies the programming interface for host connection hardware, ensuring base silicon and software driver support required for add-on devices and PC system board integration. OpenHCI for IEEE 1394 specifies basic capabilities required for the PC that uses IEEE 1394.

3. Devices comply with IEEE 1394 electrical isolation requirements

Required

Self-powered devices with their own AC power supply must provide electrical isolation between the local device ground reference (green wire) and the bus cable power signals as specified in Annex A of IEEE 1394 – 1995. This isolation is required to avoid excessive currents resulting from ground fault potential between one or more devices, particularly for buses configured in a local area network.

Isolation is typically provided in the device power supply or by AC coupling of the PHY and Link interface, Annex J of IEEE 1394 – 1995. Isolation is not required for devices that do not supply their own local ground reference (green wire).

4. Devices and PCs requiring high-bandwidth support use IEEE 1394

Recommended

For devices that need support for high-speed, high-bandwidth data transfers and enhanced Plug and Play connectivity, the recommended bus is IEEE 1394. Such devices include the following:

Component audio PCI add-on cards
Digital camcorder Hard disk drives

Digital still cameras DVD
Digital VCR Set-top controllers for TV
Digital TV Video conferencing cameras

PC docking stations High-resolution scanners and printers

PC system boards

5. Support peak data rate of 400 megabits per second, minimum

Recommended

Although 400 Mb/s is significantly higher than current PC storage I/O data rates (IDE at 132.8 Mb/s; fast SCSI at 160 Mb/s), today's magnetic disk media rates of 80 Mb/s are forecasted to double every three years. By 1998, 200 Mb/s of the IEEE 1394 bus bandwidth must be available for PC system disk I/O and asynchronous device control. Thus, 400 Mb/s bus bandwidth is required to effectively support multistreaming audio/video applications such as MPEG-2 at 6 Mb/s and DVC Standard Definition at 3.5 Mb/s concurrent with PC storage I/O.

Further, a 200-Mb/s device with a 160-Mb/s data stream will require 80 percent bus utilization, effectively lowering overall bus bandwidth to 200 Mb/s for 80 percent of the time. Therefore, low bus utilization is required for 100- and 200-Mb/s devices to effectively coexist with 400-Mb/s PC peripheral devices. For example, three devices performing at 200-Mb/s with 30-percent bus utilization will saturate the bus. recommended design targets for devices with less than 400-Mb/s bandwidth is to limit peak bus utilization to less than 30 percent.

Also, application bandwidth can be limited by speed traps (a slow device separating two faster devices), imposing speed-dependent cabling considerations for the end user. For these reasons, 400-Mb/s devices are strongly recommended for IEEE 1394 PC applications.

6. PHY supports Fast Incremental Reset

Required

The IEEE 1394.1 project is chartered to define a PHY layer protocol to reduce bus off-time following a bus reset condition. All Windows-compatible devices are required to support this protocol to minimize interruption of isochronous A/V streams.


Plug and Play for IEEE 1394 Devices

This section summarizes the Plug and Play requirements for IEEE 1394 peripheral devices and PC host controllers.

7. Devices and controllers comply with "1394 Plug and Play Design Reference"

Required

This specification outlines device requirements necessary to ensure dynamic configuration while eliminating fault conditions associated with unsupervised connection of devices to the IEEE 1394 bus. It provides details about the Device Configuration ROM, Global Unique identifier (GUID) for device detection and driver loading, and configuration of power-independent connectors and cabling.


Power Specifications for IEEE 1394 Devices

All devices on the IEEE 1394 bus must comply with the power management requirements outlined in this section.

8. Devices and controllers comply with Specification for Cable Power Distribution, from IEEE 1394 Trade Association

Required

The Cable Power Distribution model for IEEE 1394 makes it easy to implement devices that serve as the source or consume cable power by defining specific requirements for power source, power sink and self-powered devices. This model reduces cabling constraints for end users while helping to ensure power availability for both managed and unmanaged IEEE 1394 environments. The power distribution model makes it easy to use cable power by reducing the likelihood of power-fault conditions while ensuring device interoperability and power-independent cabling.

The power distribution model also helps to provide a Plug and Play-compatible cabling environment for both managed and unmanaged power environments. Requirements in this specification enable unmanaged default configurations to function. Alternately, these requirements enable managed environments with an active PC bus manager to provide an enhanced Plug and Play experience.

9. Devices and controllers comply with "1394 Power Specification" from Microsoft

Required

This specification addresses both cable (bus) powered and self-powered (AC powered) devices. The device power management architecture defines a standard Command and Status Register (CSR) protocol and IEEE 1394 device power states necessary for an intelligent bus manager to effectively manage device power consumption. Benefits include consistent device behavior, power conservation and instant ("OnNow") availability for end-user applications.

The IEEE 1394 power management architecture defines a framework for Soft Power_On, Soft Power_Shutdown, and Remote Wakeup. The architecture applies a number of key features defined in the IEEE 1394 standard to implement device power management including four standard device power states (D0 – D3), power status CSRs, and device wakeup signaling. Together, these capabilities enable power conservation while providing for OnNow-compatible device environments.


Device Command Protocol for IEEE 1394 Devices

This section summarizes command protocol requirements for integration and interoperability of the IEEE 1394 bus with IEEE 1394 peripherals such as consumer electronics devices.

10. Device command protocols conform to Win32 Device Class Interfaces

Required

Support in the Windows operating systems for new device classes (for example, Digital VCR) will leverage the Win32 Driver Model (WDM) so that a single device class driver binary will support the same devices on both Windows and Windows NT.

New Win32 device driver interfaces are based on available industry standards. Areas of standardization include generic command and protocol standards for Audio, Imaging, and Storage class interfaces, spanning multiple device types in each category. Win32 class drivers provide hardware-independent, class-specific interfaces that can be extended by hardware-specific device minidrivers.

Devices that comply with interface standards such as HCI for IEEE 1394 eliminate the need for developing and testing third-party device drivers. Other devices will require implementation of a simple minidriver to extend Microsoft-supplied generic class interfaces to support a specific device. In limited, but special cases, it might be necessary for a third party to implement both a class and a minidriver to support a new device.

11. Consumer A/V device interfaces comply with industry standards

Required

These standards include Digital Interface for Consumer Electronic Audio/Video Equipment (Draft 2.1 or later) by Philips Electronics N.V., Matsushita Electric Ind. Co., Ltd, Thomson Multimedia, Sony Corporation, October, 1995 (also available from IEEE 1394 Trade Association).

This specification outlines implementation requirements for interoperability of consumer audio/video equipment over IEEE 1394. It includes a clarifying sample of a device configuration ROM and CSRs. Specific areas for compliance are summarized here:

  • Isochronous IEEE 1394 devices support Common Isochronous Packet (CIP) Header.

    Devices capable of isochronous data handling must support the CIP format to ensure interoperability of isochronous data between consumer A/V nodes on an IEEE 1394 bus.

  • Isochronous IEEE 1394 devices support Connection Management Protocol (CMP).

    CMP is Required to enable management of isochronous connections including swift allocation and deallocation of channels following a bus reset. Plug Control Registers (PCRs) are Required to facilitate CMP necessary for isochronous data flow management.

  • Consumer A/V devices support the Function Control Protocol (FCP).

    FCP is Required for compatibility with Microsoft-supplied consumer-A/V class device drivers. (for example, digital cameras and camcorders).

    Part 1 defines command packet formats for the simple command-response FCP protocol for asynchronous control of digital A/V devices. Parts 2 and 3 specify packet format and transmission timing for Standard Definition (SD) and High Definition (HD) digital VCR data respectively.

12. Imaging devices support interface standards

Recommended

The Win32 Imaging Class drivers (for cameras, camcorders, printers, scanners, and so on) will be based on one or more of the following standards:

  • AVC command set (available from the IEEE 1394 Trade Association)
  • Specifications for consumer-use digital VCRs using 6.3mm magnetic tape (Blue Book)
  • Digital Interface for Consumer Electronic Audio/Video Equipment (draft 2.1 or later)

For more information, see the Microsoft Win32 Driver Model DDK.

13. Audio devices support interface standards

Recommended

The Win32 Audio Class driver (for component audio, musical instruments, and so on) will be implemented based on one or more of the following:

  • Human Input Device Class (http://www.teleport.com/~usb)
  • USB Audio Class (http://www.teleport.com/~usb)
  • Digital Interface for Consumer Electronic Audio/Video Equipment (draft 2.1 or later)
  • AVC Command set (available from the IEEE 1394 Trade Association)
  • Digital Audio and Performance Data Transmission Protocol and Connection Management for Electronic Musical Environment—Yamaha Corporation

For more information, see the Microsoft Win32 Driver Model DDK.

14. Support for SCSI-3 protocol

Recommended

Where feasible, designs should leverage common command protocols defined for SCSI-3. Storage devices in particular can take advantage of common commands and protocols based on Command Descriptor Blocks (CDBs):

  • SCSI-3 Serial Bus Protocol (Working Draft of X3T10 Tech. Subcommittee)

    SCSI-3 SBP specifies a command delivery protocol developed to extend existing parallel SCSI protocol to support new features (for example, isochronous data streaming) provided by the IEEE 1394 bus. The SCSI-3 SBP is intended for use with SCSI-3 primary commands for block I/O and multimedia devices.

  • SCSI-3 Multimedia Command Set (MMC) X3T10/1048D


IEEE 1394 Controller Requirements

This section summarizes class specifications and standards for IEEE 1394 controllers. These requirements are in addition to those defined in "IEEE 1394 Basic Requirements" earlier in this chapter.

15. IEEE 1394 host controllers are bus-manager capable

Required

IEEE 1394 host controllers must be bus-manager capable as specified in clause 8.3.1.6 of the IEEE 1394 – 1995 standard. This functionality is necessary for intelligent PC bus managers to provide a managed environment for Plug and Play and for power and isochronous data, including cycle master and isochronous resource manager.

The host controller must be capable of asserting the force root node assignment protocol necessary for an IEEE 1394-capable PC to be assigned the role of active bus manager.

Other bus management capabilities include the following:

  • Managing TOPOLOGY_MAP and SPEED_MAP registers.
  • Managing BANDWIDTH_AVAILABLE and CHANNELS_AVAILABLE registers.
  • Configuring the arbitration gap count for optimum bus performance.
  • Enabling Isochronous by ensuring that the root node is cycle-master capable.
  • Managing cable power distribution.
  • Managing device power consumption.

16. Host controller provides system memory protection and security

Required

Host controllers must restrict access to host memory from unqualified IEEE 1394 devices. The default after a bus reset is no access to host memory for add-on IEEE 1394 devices.

Host controllers must not provide the capability to spoof either their Node ID or the Global Unique ID using any software-accessible control.

It is acceptable if the Global Unique ID is only non-spoofable for quadlet reads from IEEE 1394 devices. Those who want to read non-spoofable Global Unique IDs should use quadlet reads, not block reads.

A host controller can spoof Node IDs only if that controller provides a hardware jumper to enable the feature (for example, for debug purposes). The state of the jumper must be detectable from software and must be disabled by default.

All IEEE 1394 devices, including host controllers, must check the source ID as well as the transaction label before accepting a response packet to satisfy an outstanding request.


References for IEEE 1394

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

IEEE 1394 Standards

ASK*IEEE
Telephone: (800) 949-4333
Fax: (415) 259-5045
Released Standards: Global Engineering, (800) 854-7179

Open Host Controller Interface Specification
Fast Incremental Reset Protocol (IEEE 1394.1 project)

http://www.skipstone.com (IEEE 1394 Trade Association web site)
Trade Association Internet reflector: IEEE 1394-sig@apple.com

"1394 Plug and Play Design Reference" from Microsoft
"1394 Power Specification" from Microsoft

http://www.microsoft.com/hwdev/specs/

Win32 Driver Model DDK for IEEE 1394, Windows 95 DDK, Windows NT DDK, and Win32 SDK

Microsoft Developer Network (MSDN) Professional membership

Digital Interface for Consumer Electronic Audio/Video Equipment
(Draft 2.1 or later)

Philips Electronics N.V., Matsushita Electric Ind. Co., Ltd, Thomson Multimedia, Sony Corporation, October, 1995

Other IEEE 1394 information can be obtained from these Internet sites:

http://www.sel.sony.com/sel/consumer/camcorder/dv.html
http://firewire.org
http://www.ti.com/sc/ieee1394


Checklist for IEEE 1394


IEEE 1394 Basic Requirements

1. Devices and controllers support IEEE 1394 standards

Required

2. Controllers comply with OpenHCI for IEEE 1394

Required

3. Devices comply with IEEE 1394 electrical isolation requirements

Required

4. Devices and PCs requiring high-bandwidth support use IEEE 1394

Recommended

5. Support peak data rate of 400 megabits per second, minimum

Recommended

6. PHY supports Fast Incremental Reset

Required


Plug and Play for IEEE 1394 Devices

7. Devices and controllers comply with "1394 Plug and Play Design Reference"

Required


Power Specifications for IEEE 1394 Devices

8. Devices and controllers comply with Specification for Cable Power Distribution, from IEEE 1394 Trade Association

Required

9. Devices and controllers comply with "1394 Power Specification" from Microsoft

Required


Device Command Protocol for IEEE 1394 Devices

10. Device command protocols conform to Win32 Device Class Interfaces

Required

11. Consumer A/V device interfaces comply with industry standards

Required

12. Imaging devices support interface standards

Recommended

13. Audio devices support interface standards

Recommended

14. Support for SCSI-3 protocol

Recommended


IEEE 1394 Controller Requirements

15. IEEE 1394 host controllers are bus-manager capable

Required

16. Host controller provides system memory protection and security

Required


Chapter 8 PCI

This chapter presents the requirements and recommendations for PCI host controllers and peripherals under the Microsoft Windows family of operating systems.

See also information about PCI-to-PC Card bridges in the "PC Cards" chapter in Part 3 of this guide.


Overview of PCI Design Issues

Microsoft supports the PCI effort within the PC industry. The effort to support PCI has uncovered related issues during operating system development and testing. Microsoft has developed some solutions for these in Windows 95 and Windows NT. Microsoft is also working on solutions for future versions of Windows and Windows NT. This chapter describes some of these issues and solutions, especially with regard to hardware design requirements.

The PCI architecture has become the most common method used to extend the PC for add-in adapters. Windows 95 and Windows NT use the basic PCI infrastructure to gain information about devices attached to the PCI bus. The ability of PCI to supply such information makes it an integral part of the Plug and Play architecture in Windows.


PCI Basic Requirements

This section summarizes the basic design requirements for PCI.

1. PCI Local Bus Specification 2.1 (or higher)

Required

All cards, bridges, and devices that use PCI must be designed to meet the requirements defined in PCI specification version 2.1 or higher.

2. No ghost cards in system

Required

A computer must not include any "ghost cards," which are cards that do not correctly decode transaction Type 1 cycles and so appear on all buses because the ghost card's PCI Configuration Space appears in more than one bus/device/function coordinate. This also includes, for example, devices that ignore some Type 0 transaction bits and therefore appear at multiple device/function addresses.

A PCI card should be visible through hardware configuration access at only one bus/device/function coordinate.

3. Standard method used to close BAR windows on nonsubtractive decode PCI bridges

Required

Setting the Base Address Register (BAR) to its maximum value and the limit register to zeroes should effectively close the I/O or memory window referenced in that bridge BAR.

4. PCI docking through a bridge connector

Recommended

Microsoft recommends docking through a bridge connector, with the actual bridge on the docking station (not on the mobile unit). The bridge can be positive or subtractive decoding. The bridge should create a new bus number so that devices behind the bridge are not on the same bus number as other devices in the system.

After a warm dock, the BIOS should not configure the bridge nor any other devices in the docking station. That is the responsibility of the operating system.

Microsoft recommends putting the PCI-to-ISA bridge on the docking station, and having no PCI-to-ISA bridge on the mobile unit. Mobile PCs typically have no ISA expansion slots, and the ISA devices on the mobile PC can be controlled by the Plug and Play interface. For more information on requirements for docking station systems, see the "Basic PC 97" chapter in Part 2 of this guide.

Notice that implementing delayed transactions for PCI-to-PCI and PCI-to-ISA docking bridges are required in the PCI 2.1 specification only when certain timing conditions are not met. For PC 97 design requirements, the PCI 2.1 specification is interpreted to mean that delayed transactions are required only when "targets cannot complete the initial data phase within the requirements of this specification," as stated in the PCI 2.1 specification. Delayed transactions are a hardware-related timing issue (and will provide a performance advantage) but are not related to operating system requirements.


PCI Controller Requirements

This section summarizes PCI standards for controllers.

5. System board bus complies with PCI 2.1 (or higher)

Required

The system board bus hardware should comply with the written specifications. The bus design must fully implement all bus requirements on every expansion card connector.

6. Allow bus master privileges for all connectors

Required

To ensure full Plug and Play functionality on a PCI bus with expansion cards, all PCI connectors on the system board must be able to allow any PCI expansion card to have bus master privileges.

7. ISA Write Data Port address propagated to ISA bus at power-up

Required

If the system uses an ISA bus in conjunction with a PCI bridge, the Plug and Play ISA Write Data Port address must be propagated at all times through the bridge to all ISA buses that might contain external ISA Plug and Play cards. The address must be propagated at power-up and system reset. This will ensure that the system can identify, isolate, and configure external Plug and Play ISA cards plugged into the ISA bus during the boot process.

8. Writable PCI Configuration Space bits not shared by CardBus controllers

Required

CardBus controllers are 32-bit multifunction PCI devices, and Windows treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits (such as the Command register).

Notice that the PC Card 16-bit Interface Legacy Mode Base Address Register (offset 44h in the Type 2 PCI header) is the only exception to this requirement. This register must be shared between the two functions, as they must share the same registers for compatibility with the Exchangeable Card Architecture defined by Intel (ExCA programming model, as defined in the "Yenta" specification).

For more information about design requirements for CardBus controllers, see the "PC Card" chapter in Part 3 of this guide.


Plug and Play for PCI Controllers and Peripherals

This section summarizes the Plug and Play requirements for PCI devices.

Note The recommendation for PC 95, "PCI-to-PCI bridge configured but not enabled by the BIOS," is replaced in PC 97 by the requirement in this section for BIOS support for IRQ routing.

9. PCI 2.1 Configuration Space for Plug and Play device identifier

Required

The PCI specification describes the configuration register space used by the system to identify and configure each device attached to the bus. This configuration space is made up of a 256-byte field for each device and contains sufficient information for the system to identify the capabilities of the device. Configuration of the device is also controlled from this register space.

The configuration register space is made up of a header region and a device-dependent region. Each configuration space must have a 64-byte header at offset 0. All of the device registers that the device circuit uses for initialization, configuration, and catastrophic error handling must fit within the space between byte 64 and byte 255. All other registers that the device uses during normal operation must be located in normal I/O or memory space. Unimplemented registers or reads to reserved registers must complete normally and return zero (0). Writes to reserved registers must complete normally, and the data must be discarded.

10. PCI Specification 2.1 Subsystem IDs

Required

The following diagram shows the two registers added to the Configuration Space Header for PCI Specification 2.1. Although these registers are only recommended in the PCI specification, they are mandatory for PC 97. Support of these registers requires non-zero values to be populated for both the Subsystem ID and Subsystem Vendor ID. These values must be populated prior to the system BIOS or system software accessing the PCI configuration space, as stated in the PCI 2.1 specification. The recommended method for populating these registers is by using serial ROMs.

New registers in configuration space header for PCI version 2.1

31 | 16 | 15 | 0
Subsystem ID | Subsystem Vendor ID | 2Ch |

These fields are important for the correct enumeration of a device. When the Subsystem fields are populated correctly for your adapter, Windows 95 can differentiate between adapters based on the same PCI chip.

The Subsystem IDs also allow Windows to load system miniports for system board devices. Thus, Subsystem IDs are also required on system board devices, but not for core chip sets.

The exceptions to this requirement are PCI-to-PCI bridges and core chip sets.

11. Configuration space populated correctly

Required

Windows 95 places extra constraints on a few configuration registers and has uncovered some problem usage of other registers. Microsoft provides a program named Pci.exe to help you debug the use of your configuration space. This program is available on the Microsoft FTP server, as described in the "Resources and References for PCI" section at the end of this chapter.

The following items are specific requirements for the configuration space:

  • Populate the Class Code Register (09h) for all devices.

    Follow the Base Class, Sub-Class, and Programming Interface values outlined in the PCI 2.1 specification.

  • Devices must not fill Base Address Registers with random values.

    Devices must not attempt to fill in random values to these registers. See the PCI 2.1 specification for the correct usage of these registers. Notice that Base Address Registers (10, 14, 18, 1C, 20, and 24h) should return zero (0) if they are not used, indicating that no memory or I/O space is needed.

Also, for performance reasons, it is recommended that runtime registers for PCI devices should not be placed in the configuration space.

12. BIOS support for IRQ routing, for x86-based systems

Required

The BIOS must support IRQ routing using the method defined in the PCI 2.1 IRQ Routing engineering change request (ECR). The addition of IRQ routing support in PCI 2.1 allows the operating system better control over PCI interrupt routing, allowing the operating system to configure bridges and devices beyond bridges.

Note The BIOS should support a "BIOS Flag" that the OEM sets, selecting by inference the level of PCI support within the operating system, depending on which operating system is installed in the factory or selected by the end user. The BIOS should allow the OEM to select between MS-DOS/Windows 3.11, Windows 95, and future Windows versions, thereby informing the BIOS about how much of the PCI configuration and enabling work should be done.

13. BIOS does not configure I/O systems to share PCI interrupts

Recommended

This applies to boot devices configured by the BIOS on x86-based systems. All other devices should be configured by Windows. Design the BIOS so that it does not configure the I/O systems in the PC to share PCI interrupts for boot devices.

Windows 95 does not support sharing an IRQ between real-mode and protected-mode code within the I/O subsystem — an example could be, an NDIS 2 driver (real mode) and a SCSI miniport driver (protected mode) for two PCI devices that share the same IRQ. The problem is the IRQ needs to be reflected to real mode for the NDIS 2 driver to work. However, if the IRQ is reflected to real mode, the real-mode SCSI driver (which usually is not called because Windows 95 takes over in protected mode) might touch the hardware, which would cause the SCSI miniport to be confused. Windows 95 solves this problem by switching everything either to protected mode or by falling back to real mode.

14. BIOS configures device IRQ and writes to the Interrupt Line Register

Required

This applies to boot devices configured by the BIOS on x86-based systems. All other devices should be configured by Windows, because after an IRQ is assigned by the system BIOS, Windows cannot change the IRQ if necessary. If the BIOS assigns the interrupt and Windows needs it for another device, an IRQ sharing problem occurs.

The BIOS must configure the device IRQ and write the IRQ into the Interrupt Line Register 3Ch, even if the BIOS does not enable the device. This way, Windows can still enable the device with the known IRQ, if possible, at configuration time. Otherwise, if the IRQ is not known, there is no way that Windows can enable the device, even if all other resources are available.


Power Management for PCI Controllers and Peripherals

This section summarizes the specific power management requirements for PCI.

15. Compliance with PCI Bus Power Management Interface Specification

Required

The PCI bus, any bridges on the bus, and all devices on the PCI bus must comply with the PCI Bus Power Management Interface Specification. This specification provides definitions of the OnNow device power states (D0 – D3) for PCI devices. It also covers bus functionality expected in each power state and the mechanism for signaling wakeup events over the bus. For PC 97, PCI bus implementations must support all four device and bus power states, as well as the standard wakeup mechanism.

At a minimum, integrated PCI devices must support the D0 and D3 power states. See the device class sections for additional power state and wakeup requirements.

This specification will allow Windows to power manage PCI devices individually to conserve power and to allow PCI peripherals to wake up the PC system when the need arises.


Design Features for PCI Devices

Specific requirements related to devices that use PCI are defined in the following chapters:

  • Requirements for dual IDE adapters that use PCI are defined in "ATA and ATAPI" in Part 3 of this guide.
  • Requirements for graphics devices that use PCI are defined in "Graphics Adapters" in Part 4 of this guide.
  • Requirements for audio implementations that use PCI are defined in "Audio Components" in Part 4 of this guide.


References and Resources for PCI

The following lists some of the services and tools available to help build hardware that works with Windows operating systems.

Microsoft testing tools, specifications, and information

http://www.microsoft.com/hwtest/
http://www.microsoft.com/hwdev/busbios/pcidsgn.htm
ftp://ftp.microsoft.com/developr/drg/plug-and-play/pci/pci.exe
E-mail: pciinfo@microsoft.com

PCI Special Interest Group

For information about current revisions of all PCI specifications and about joining the PCI Special Interest Group, contact the PCI-SIG:
Phone: (800) 433-5177
http://www.pcisig.com/

See also the papers available from the PCI-SIG, including the Compliance Checklist Rev. 2.1, at http://www.teleport.com/~pc2/reldocs.htm

PCI Bus Power Management Interface Specification

http://www.microsoft.com/hwdev/onnow.htm

"Yenta" specification: PCI to PCMCIA CardBus Bridge Register Description

Published by Intel Corporation, available to all "Yenta" members.
Phone: (800) 879-4683


Checklist for PCI


PCI Basic Requirements

1. PCI Local Bus Specification 2.1 (or higher)

Required

2. No ghost cards in system

Required

3. Standard method used to close BAR windows on nonsubtractive decode PCI bridges

Required

4. PCI docking through a bridge connector

Recommended


PCI Controller Requirements

5. System board bus complies with PCI 2.1 (or higher)

Required

6. Allow bus master privileges for all connectors

Required

7. ISA Write Data Port address propagated to ISA bus at power-up

Required

8. Writable PCI Configuration Space bits not shared by CardBus controllers

Required


Plug and Play for PCI Controllers and Peripherals

9. PCI 2.1 Configuration Space for Plug and Play device identifier

Required

10. PCI Specification 2.1 Subsystem IDs

Required

11. Configuration space populated correctly

Required

12. BIOS support for IRQ routing, for x86-based systems

Required

13. BIOS does not configure I/O systems to share PCI interrupts

Recommended

14. BIOS configures device IRQ and writes to the Interrupt Line Register

Required


Power Management for PCI Controllers and Peripherals

15. Compliance with PCI Bus Power Management Interface Specification

Required


Chapter 9 ISA

This chapter presents the requirements and recommendations for ISA under the Microsoft Windows family of operating systems.


Overview for ISA

This section summarizes the basic requirements for a PC system that includes Industry Standard Architecture (ISA). In PC 97, ISA must be implemented with full support for Plug and Play ISA boot devices. For any ISA device that cannot meet the resource requirements specified for its device class, the device and driver must implement IRQ sharing, as described later in this chapter.

In addition to expansion cards designed to use ISA, the following are also ISA devices:

  • 8042 and similar controllers, ports, keyboards, and mice
  • Direct memory access (DMA) controllers and slaves
  • Floppy disk controllers (FDC)
  • Interrupt controllers
  • Legacy parallel and serial ports
  • Math coprocessors
  • Programmable interrupt timers (PIT)
  • VGA controllers

Any such devices located at I/O addresses under 100h can use fixed resources and are exempt from Plug and Play requirements for unique IDs, flexible resource configuration, and dynamic disable capabilities.

The following ISA devices have additional requirements defined in this guide:

  • 8042 port and device requirements are defined in the "Input Components" chapter in Part 4 of this guide.
  • Legacy FDC requirements are defined in the "Storage and Related Peripherals" chapter in Part 4 of this guide.
  • Legacy parallel and serial ports and related device requirements are defined in the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.


System Requirements for ISA

This section summarizes the basic design requirements for ISA. All ISA cards that receive a "Designed for Microsoft Windows" logo must meet the requirements defined in this section in addition to meeting the general expansion card requirements as defined in the "Basic PC 97" chapter in Part 2 of this guide.

1. ISA support in PC system

Optional

System designers are encouraged to consider designing PC systems that do not include the ISA bus or that do not allow for end-user insertion of ISA devices, and hardware vendors are encouraged to plan for complete migration away from ISA.

The requirements listed in this chapter apply only if the manufacturer chooses to include ISA support in a system.

2. System supports Plug and Play ISA specification and Plug and Play BIOS

Required

If ISA support is included in a PC 97 system, the manufacturer must implement the standards described in the following Plug and Play specifications:

  • Plug and Play ISA Specification v. 1.0a
  • Plug and Play BIOS Specification v. 1.0a
  • Clarifications to the Plug and Play BIOS Specification v. 1.0a.

A Plug and Play – compliant system can identify the Plug and Play ISA cards and the resources they use, then program these resources so they do not conflict. The conflict-resolution scheme used on Plug and Play ISA cards essentially puts all cards "to sleep," then reads the card identification, the information about what the card can do, and the resources it requires. This information can include what resources are programmable and the ranges they can be programmed. With this information, the system can configure the card in a way that prevents conflicts with other cards in the ISA bus.

For this procedure to work, the system must completely implement the related requirements defined in the Plug and Play ISA specification and the Plug and Play BIOS specifications.

Note Standard system devices are excluded from this requirement. The system can reserve static resources for devices such as interrupt controllers 1 and 2, timer (8254-2), keyboard controller (8042), real-time clock, DMA page registers, DMA controllers 1 and 2, and math coprocessor (if present). For an x86-based system, these fixed resources are located at I/O addresses under 100h and can also include an NMI mask.

3. BIOS configures ISA cards on non – Plug and Play operating systems

Required

The system BIOS must properly configure all Plug and Play ISA cards in the PC system if a non – Plug and Play operating system is loaded.

To identify whether a Plug and Play operating system is present, the BIOS first evaluates the master boot record to find the partition from which to boot and then determines whether that partition is a Windows 95 partition. The Windows 95 signature in the partition boot sector is the string "MSWIN4.0" located at offset 03h in the partition boot record.


Plug and Play for ISA Devices

This section summarizes the Plug and Play requirements for ISA cards. For more complete details, see the Plug and Play ISA specification and also Hardware Design Guide for Microsoft Windows 95 (Microsoft Press, 1994). This section includes additional requirements for ISA cards to ensure that such cards will perform correctly under Windows 95, including requirements for design implementations that appear only as recommendations in the ISA specification.

4. ISA device complies with Plug and Play ISA standards

Required

Any card or bus that implements Plug and Play ISA must fully implement the standards defined in the Plug and Play ISA Specification v. 1.0a. This specification also defines the requirements for a unique ID for each ISA device, which is used to identify the device for Plug and Play configuration.

5. Option ROMs used only on cards with boot devices

Required

This requirement applies only for x86-based systems. Option ROMs must be used only on cards that contain boot devices.

Cards with option ROMs must not hook the primary boot interrupts (Int 9h, Int 10h, Int 13h, Int 18h, and Int 19h) until the system calls the boot connection vector in the selected option ROM expansion header.

On cards with option ROMs, the default configuration must be able to be disabled after the card has been isolated.

6. Implement full 16-bit I/O address decode logic

Required

This can be a simple circuit limiting I/O addresses to the 0h to 3FFh range, or can be flexible enough to use the upper address regions. For more information, see the "Basic PC 97" chapter in Part 2 of this guide.

7. ISA device and driver support IRQ sharing if resource requirements cannot be met

Required

This is a requirement only if the device cannot meet the PC 97 resource requirements (as defined for the particular device class in the related chapter in Part 4 of this guide). This requirement for sharing IRQs applies for devices of the same class, not across device classes.

To share IRQs, the following requirements must be met:

  • The IRQ line must be pulled high by the system board.
  • Devices must never drive the IRQ line high.
  • To signal an interrupt, devices must pull the IRQ line low for a minimum of 100 nanoseconds and then release it. The interrupt is signaled by the rising edge that occurs as a result of the pull-up on the IRQ line.
  • The drivers for all devices connected to the IRQ line must correctly support the interrupt-sharing services of the virtual programmable interrupt controller device (VpicD). This means that after being dispatched an interrupt from VpicD, the drivers must respond to VpicD and indicate correctly whether they actually processed an interrupt for their devices. VpicD will ensure that all devices with pending interrupts have been serviced before returning from the interrupt.
  • IRQ sharing support implemented in the device driver for servicing interrupts.

8. Unimplemented registers return a deterministic value when read

Required

Any unimplemented registers in the range 00h through 2Fh must return a deterministic value when they are read. Unimplemented configuration registers must return the "disabled" or "unused" value (not necessarily 0) when they are read.

9. Correct IDs for each ISA card

Required

In the Plug and Play ISA specification, it is required that a Plug and Play card have both an industry-unique Vendor ID (acquired by sending e-mail to pnpid@microsoft.com) and a company-unique Product Identifier (assigned by the manufacturer). The specification requires that this product identifier be unique among all Plug and Play ISA cards manufactured by that company. This means each product (for example, fax card, display adapter, sound adapter, and so on) and every model (for example, 14.4 fax, 28.8 fax, and so on) from the same manufacturer must have different product identifiers.

This is a PC 97 requirement, because it allows the operating system to isolate and identify these different cards. The user must never have a Plug and Play card that cannot be identified because it cannot be distinguished from other models of cards from the same manufacturer. The use of a unique Product ID does not solve the problems that occur when a user installs two of the same cards in a PC system.

In these cases, the user might install a Plug and Play card but will get no indication that it was installed and the card will not work. For this purpose, the Plug and Play ISA specification defines a unique serial number field that can be added to the Vendor and Product IDs to make the card completely unique. A board-unique number in the serial number field is required for ISA devices included on a PC 97 system.

10. ISA system board devices report through BIOS or use unique Serial ID

Required

A peripheral ISA device implemented on the system board can use a fixed Serial IDs (which is not unique) if the device is reported through the BIOS.

If the system board device participates in the Plug and Play ISA isolation scheme (rather than being reported through the BIOS), then it must meet the same requirement for a unique Serial ID as required for an add-on card.

Notice that it is possible that an add-on card containing an ISA chip might be added to a PC system that contains the same chip on the system board. In such a case, the add-on device will be found only if it has a different Serial ID.

11. IDs using PNP suffix allowed only in Compatible Device ID field

Required

Device IDs that use the three-character PNP suffix are allowed only in the Compatible Device ID field and cannot be used as Device IDs or Logical Device Ids (except, of course, for the device to which the PNP-based ID was originally assigned).

Resource data describes what resources must be available for each logical device on the card (for example, number of available IRQ numbers, address ranges of memory, and so on). Resource data can be stored in the same nonvolatile storage device (such as a serial ROM) that contains the serial identifier. The resource data in the nonvolatile storage device must be sequentially loaded into the resource data register (04h).

The contents of the nonvolatile storage device must be programmed with the information the system needs to interpret which resources the card requires. The structure of the data contained in the storage device is variable, depending on what resources are needed.

The resource data for a Plug and Play ISA card can be read while the card is in the Config state. This card can enter the Config state either after it has been isolated during the isolation sequence, or whenever it receives a Wake[CSN] software command in which the CSN matches the CSN assigned to the card. Only one card at a time can be in the Config state.

12. Correct support for boot devices

Required

Plug and Play ISA expansion cards that contain boot devices require some special considerations to properly boot the system. For PC 97, the system must implement support for Plug and Play ISA boot devices and option ROMs as described in the Plug and Play BIOS Specification v. 1.0a.

The types of devices required for the boot process include the primary input device (usually a keyboard), the primary output device (usually a display adapter and a monitor), and any IPL devices.

Any Plug and Play ISA expansion card that provides a boot function must be active when the system powers up. This gives non-Plug and Play systems the means for using Plug and Play ISA devices during a "legacy" boot process. In this case, a non-Plug and Play system BIOS will not perform the isolation sequence but will instead perform a ROM scan to detect the presence of a boot device. After the ROM scan detects the presence of an option ROM on the boot device, the system ROM will jump to the option ROM to initialize the device. The Plug and Play option ROM on the card will detect that the system BIOS is not Plug and Play compatible and will respond accordingly. Although an initial set of static resources must be provided during this "legacy" boot, the Plug and Play ISA card must be capable of changing these resources using the standard Plug and Play ISA isolation and configuration process.

As required in the Plug and Play ISA specification, resource usage of a card is always reflected in the card's configuration registers. This information allows Windows 95 to easily determine the default settings of a Plug and Play boot device. The default settings can then be overridden by the operating system with full cooperation of the device driver.


Power Management for ISA

There are no power management requirements for ISA.


References for ISA

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Plug and Play ISA Specification v. 1.0a
Plug and Play BIOS Specification v. 1.0a
Clarifications to Plug and Play BIOS Specification v. 1.0a

http://www.microsoft.com/hwdev/pnpspecs.htm

Clarifications and white papers on bus issues

http://www.microsoft.com/hwdev/busbios/


Checklist for ISA


System Requirements for ISA

1. ISA support in PC system

Optional

2. System supports Plug and Play ISA specification and Plug and Play BIOS

Required

3. BIOS configures ISA cards on non – Plug and Play operating systems

Required


Plug and Play for ISA Devices

4. ISA device complies with Plug and Play ISA standards

Required

5. Option ROMs used only on cards with boot devices

Required

6. Implement full 16-bit I/O address decode logic

Required

7. ISA device and driver support IRQ sharing if resource requirements cannot be met

Required

8. Unimplemented registers return a deterministic value when read

Required

9. Correct IDs for each ISA card

Required

10. ISA system board devices report through BIOS or use unique Serial ID

Required

11. IDs using PNP suffix allowed only in Compatible Device ID field

Required

12. Correct support for boot devices

Required


Chapter 10 ATA and ATAPI

This chapter presents the requirements and recommendations for ATA (AT Attachment), ATAPI (AT Attachment Packet Interface) controllers, and peripherals designed to work with the Microsoft Windows family of operating systems. ATA is commonly known as IDE (Integrated Drive Electronics).


Overview for IDE and ATAPI

This section summarizes the basic design requirements for Windows-compatible IDE hardware, including adapters, peripherals, and any device that uses an IDE controller.

The ATA/IDE interface is one of the most widely used in the PC world. Originally intended only for hard drives, IDE support is being extended to additional device types and performance features.

The major issues for IDE and ATAPI devices for PC 97 are the following:

  • Accommodating the growing class of removable media devices.

    A major shortcoming of removable media devices on PC platforms is their inability to report to the host when the user attempts to eject the medium. Devices must have a means of communicating to the host that the user wants to eject the medium or has inserted a new medium. The solution required by Microsoft is the Media Status Notification Specification (v. 1.03 or higher), which defines a protocol for such support. The support is enabled using a SET FEATURES command, and the media status is retrieved using a new ATA command, GET MEDIA STATUS.

  • Support for the "fixed disk access" subset of Int 13h Extensions must be provided in the system BIOS and in any option ROMs for storage devices that include BIOS support.
  • Power management for IDE and ATAPI devices.

    Support for the ATA STANDBY command continues to be required. New power management requirements are also defined.

    The overall power management design initiative is described in Part 1 of this guide. The specific power management requirements for IDE are defined in this chapter. Additional requirements for storage devices are defined in the "Storage and Related Peripherals" chapter in Part 4 of this guide.


IDE Controllers Requirements

This section summarizes the specifications and standards for Windows-compatible IDE controllers.

1. Compliance with ATA-2 specification

Required

Recommended: ATA-3 compliance.

All IDE adapters (and peripherals) must meet the hardware and software design requirements listed in the current version of the AT Attachment 2 specification.

2. Support Int 13h Extensions in BIOS and option ROMs

Required

The Int 13h Extensions ensure correct support for high-capacity drives, consistent drive-letter mapping between real mode and protected mode, and other capabilities for both Windows 95 and Windows NT. Support for the "fixed disk access" subset of Int 13h Extensions must be provided in the system BIOS and in any option ROMs for storage devices that include BIOS support. The Int 13h Extensions are defined in "Int 13h Extension APIs" in the Layered Block Device Drivers section of the Windows 95 DDK.

3. Media Status Notification support v. 1.03 or higher

Required

The Microsoft specification for Media Status Notification support (v. 1.03 or higher) defines the protocol for ATA and ATAPI devices to use in communicating about the current state of removable media.

4. Dual IDE adapters run in Native mode with PCI IDE bus mastering

Required

Dual IDE devices allow for writing data to both devices with the expectation that the data is to be serialized outside of the device. If PCI IDE bus mastering is implemented, dual IDE adapters must be built to run in Native mode and must be compliant with the PCI IDE Controller Specification (revision 0.9, dated May 1994, or later versions). When a device is enabled, whether in Native or Compatibility mode, it must be able to report whether it is programmable in Native mode, so that Windows can move the device's resources if necessary.

Native mode is not required for integrated IDE in a south bridge multifunction device that supports Compatibility mode for Programmed Input/Output (PIO).

5. Dual IDE adapters use single FIFO with asynchronous access or dual FIFOs and channels

Required

PCI dual IDE adapters must be designed so that either channel might be used at any time — that is, the operating system does not have to serialize access between the primary and secondary channel at any time. This means that either the two channels are totally independent or that anything which is shared, such as a PIO read prefetch buffer, is protected by a hardware arbitrator.

A design implementing a single FIFO that uses a hardware solution to synchronize access to both channels meets this requirement if the design does not require a request on one channel be completed before the other can be started.

The Compaq, Intel, Phoenix BIOS Boot Specification (Section 5.0) defines the implementation for dual asynchronous channels.

Dual-channel controllers that require special software to serialize channel I/O for a single prefetch FIFO do not qualify for the "Designed for Microsoft Windows" logo. Such designs require serial access to one of four devices, defeating the primary advantage of asynchronous dual-channel controllers. Further, such devices are non-standard and require custom driver support. Microsoft strongly discourages introduction of non-standard IDE hardware, because it negatively impacts traditional compatibility of the IDE interface. Notice, however, that dual-channel controllers that do not require special software to serialize channel I/O do qualify for the logo.

6. Support for LBA in system BIOS

Required

To enable support for IDE disk drives larger than 528 MB, the system BIOS must use a logical block addressing (LBA) scheme that is compatible with the BIOS/CMOS and IDE register set constraints.

Although ATAPI was defined to be transparent to the BIOS, the BIOS must recognize the presence of ATAPI devices using the signature as defined in SFF 8020i. In some cases, without such support the BIOS might fail to configure the adapter if it does not see a device.

7. PCI IDE bus master DMA compliant with SFF 8038i

Recommended

The programming register set for PCI IDE bus master DMA is defined in Small Form Factor (SFF) 8038i. IDE drives should be compliant with SFF 8038i to ensure fully-featured hardware and Windows-compatible device driver support.

With ATAPI CD-ROM, PIO demands placed on the system CPU can have a negative impact on system performance and application processing, especially for multimedia. Bus master DMA IDE adapters, which leverage local bus data rates, can provide higher data rates and the ability to offload the system CPU from I/O transfers. Other factors that encourage the adoption of bus master DMA include the increased disk media transfer rates, plus the demands made by multitasking operating systems and multichannel/multidevice IDE configurations.

Note This will become a requirement in 1998.

8. Support for fast PIO modes

Required if no bus mastering

Note This is required if PCI IDE bus mastering is not implemented. This alternate implementation can be used instead of PCI IDE bus master DMA for PC 97.

Fast PIO mode timing is defined in ATA-2, but the BIOS support should set up fast PIO mode transfers to accommodate chip-specific implementations, because an industry-standard programming interface does not exist for setting up timing.

Various problems have been observed with 32-bit PIO adapters. Manufacturers who implement 32-bit PIO for IDE adapters must follow the ATA-2 signal protocol to ensure that data integrity is preserved and to eliminate potential problems with early ISR entry.

9. Support SFF 8020i Section 10.0 (Cable Select) for master-slave configuration

Required

SFF 8020i Section 10.0 (v. 1.2 or higher) defines the cabling and connectors required for automatic configuration of a device as master (dev0) or slave (dev1) on a given channel.

10. Pin 1 cable designation for connections

Required

Pin 1 orientation must be designated by one edge of the ribbon cable and also on the keyed connector of the IDE or ATAPI peripheral device.


Plug and Play for IDE Controllers and Peripherals

This section summarizes the Plug and Play requirements for IDE controllers and peripherals.

11. Plug and Play device identifier

Required

  • For a system board device, there must be a Plug and Play device-specific ID.
  • Each IDE device must provide device identifiers in the manner required for the bus it uses, as defined in Part 3 of this guide.

    For example, an add-on PCI IDE device must comply with PCI 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide. PCI IDE controllers integrated into core logic on the system board do not have to provide Subsystem IDs and Vendor Subsystem IDs, but must meet the other requirements in the PCI 2.1 specification.

12. Dynamic resource configuration for all devices

Required

Changing or adding a controller to the system must not require changing jumpers or switches on either the controller or the system board.

13. Resource configuration per bus requirements

Required

Plug and Play resource configuration requirements are defined by the bus used by the IDE device, as defined in the related chapters in Part 3 of this guide. For non-PCI devices, the following is required:

  • Support for two ranges: 1F0h – 1F7h, 3F6h and 170h – 177h, 376h.

    Using the standard addresses ensures the proper functioning of software written for legacy systems. Support for alternate I/O addresses 170h – 177h ensures support for enhanced IDE.

  • Support for IRQ 14 and IRQ 15.

14. 3F7h and 377h not claimed by IDE devices

Required

Although IDE device might use these addresses, 3F7h and 377h also contain registers used by the floppy disk controller. To prevent resource conflicts, these addresses must not be claimed as resources in device registers.


Power Management for IDE Devices

This section summarizes the specific power management requirements for IDE. Power management requirements for peripherals that use IDE are defined in the related device-class chapters in Part 4 of this guide.

15. Correct support for ATA STANDBY

Required

The IDE drive must implement the ATA STANDBY command according to the ATA standard to ensure that the drives are able to spin up properly after a STANDBY command.

16. Power requirements for bus and device

Required

The IDE channel must comply with the "Device Class Power Management Reference Specification" for the storage device class. Additional power management requirements are specified based on industry-defined standards for the bus used by the controller (such as PCI) and for the device. For information, see the chapter for the related bus class in Part 3 in this guide.


Design Features for IDE and ATAPI Peripherals

This section summarizes requirements related to specifications and standards for IDE and ATAPI peripherals.


ATAPI Peripheral General Requirements

This section defines the requirements for all ATAPI devices.

17. Compliant with SFF 8020i v. 1.2 or higher

Required

This specification defines standard hardware and software design guidelines for ATAPI devices. Notice additional requirements for BIOS support of Int 13 Extensions earlier in this chapter.

18. All ATAPI devices enumerated by BIOS compliant with SFF 8020i v. 2.5

Required

ATAPI specification SFF 8020i v. 2.5 defines the process for enumeration of all ATAPI devices.

19. Media Status Notification support v. 1.03 or higher

Required

The Microsoft specification for Media Status Notification support (v. 1.03 or higher) defines the protocol for ATA and ATAPI devices to use in communicating about the current state of removable media.

20. Automatic configuration of firmware based on CSEL configuration

Required

SFF 8020i Section 10.0 (v. 1.2 or higher) defines the cabling and connectors required for automatic configuration of a device as master (dev0) or slave (dev1) on a given channel. This required Cable Select (CSEL) support eliminates the need for master-slave jumpers on the drive.

The implementation for boot drive determination in multiple-drive systems is defined in the Compaq, Intel, Phoenix BIOS Boot Specification (Section 5.0). This is the format Windows operating systems will use as the consistent method for determining the boot drive as new bootable devices are introduced for PCs. The system designer can use an equivalent method for boot drive determination, but the method must ensure that the boot drive is recognized by the Windows 95 and Windows NT operating systems.

21. Pin 1 cable designation for connections

Required

Pin 1 orientation must be designated by one edge of the ribbon cable and also on the keyed connector of the IDE or ATAPI peripheral device.

22. ATAPI RESET supported in hardware, per SFF 8020i v. 1.2

Recommended

Ensure that the ATAPI RESET command is processed by the peripheral, even if the firmware state cannot be determined. Reset the controller by going into a power-up state (clear requests, signature present), except leave any nondefault Mode values in their current state and leave the DRV bit unchanged (Section 6.2 of SFF 8020i v. 1.2 or higher).

23. PCI IDE bus mastering compliant with SFF 8038i

Recommended

IDE devices should comply with Small Form Factor (SFF) 8038i to ensure fully-featured hardware and Windows-compatible device driver support.

Note This will become a requirement in 1998.

24. SMART-compliant drive uses SMART IOCTL API

Optional

The SMART IOCTL API Specification published by Compaq Computer Corporation and Microsoft Corporation (v. 1.1 or higher) describes the API for an application to issue SMART commands to an IDE drive under Microsoft Windows. In Windows 95, the API is implemented in a Vendor Specific Driver (VSD), Smartvsd.vxd.


IDE CD-ROM Peripheral Requirements

This section defines requirements for CD-ROM devices attached to an IDE adapter.

25. Compliant with SFF 8020i v. 1.2 (or higher)

Required

CD-ROM drives attached to the PC system must support the hardware and protocols documented in the ATA Packet Interface for CD-ROMs, SFF-8020i v. 1.2 (or higher).

26. Support multisession and compatibility forms of READ_TOC

Required

Implement both multisession forms of the READ_TOC command (01b and 10b), as well as the compatibility form (00b). This ensures complete support for multisession capabilities for CD-ROM.


IDE Floppy Drive Peripheral Requirements

This section presents the requirements for IDE floppy drives.

27. IDE floppy drive compliant with SFF 8020i v. 2.6

Required

This version of the SFF 8020i specification defines implementation requirements that the Windows operating system supports, including support for ATA floptical drives.


IDE DVD Peripheral Requirements

This section presents the requirements for DVD that uses IDE. For complete requirements related to DVD, see the "Storage and Related Peripherals" chapter in Part 4 of this guide.

28. IDE DVD compliant with SFF 8020i v. 3.0

Required

This version of the SFF 8020i specification defines implementation requirements that the Windows operating system supports.


References for IDE and ATAPI

This section lists some of the publications, services, and tools available to help build hardware that work with Windows operating systems.

Media Status Notification specifications
SMART IOCTL API Specification v. 1.1 or higher

http://www.microsoft.com/hwdev/specs/

ATA 2 [X3T9.2 948D]
ATA Packet Interface for CD-ROM, SFF 8020I

Global Engineering Documents
15 Inverness Way East
Englewood, CO 80112-5704
Phone: (800) 854-7179
Outside U.S. and Canada: (303) 792-2181
Fax: (303) 397-2740

Compaq, Intel, Phoenix BIOS Boot Specification v. 1.01

http://www.ptltd.com/techs/specs.html

Programming Interface for Bus Master IDE, SFF 8038i Rev. 1.0
and other Small Form Factor Committee (SFF) documents

FaxAccess: (408) 741-1600 (faxback)

Windows 95 DDK and Windows NT DDK

MSDN Professional membership
The Windows 95 DDK includes the "Int 13h Extensions API."


Checklist for ATA and ATAPI


IDE Controllers Requirements

1. Compliance with ATA-2 specification

Required

2. Support Int 13h Extensions in BIOS and option ROMs

Required

3. Media Status Notification support v. 1.03 or higher

Required

4. Dual IDE adapters run in Native mode with PCI IDE bus mastering

Required

5. Dual IDE adapters use single FIFO with asynchronous access or dual FIFOs and channels

Required

6. Support for LBA in system BIOS

Required

7. PCI IDE bus master DMA compliant with SFF 8038i

Recommended

8. Support for fast PIO modes

Required if no bus mastering

9. Support SFF 8020i Section 10.0 (Cable Select) for master-slave configuration

Required

10. Pin 1 cable designation for connections

Required


Plug and Play for IDE Controllers and Peripherals

11. Plug and Play device identifier

Required

12. Dynamic resource configuration for all devices

Required

13. Resource configuration per bus requirements

Required

14. 3F7h and 377h not claimed by IDE devices

Required


Power Management for IDE Devices

15. Correct support for ATA STANDBY

Required

16. Power requirements for bus and device

Required


Design Features for IDE and ATAPI Peripherals

ATAPI Peripheral General Requirements

17. Compliant with SFF 8020i v. 1.2 or higher

Required

18. All ATAPI devices enumerated by BIOS compliant with SFF 8020i v. 2.5

Required

19. Media Status Notification support v. 1.03 or higher

Required

20. Automatic configuration of firmware based on CSEL configuration

Required

21. Pin 1 cable designation for connections

Required

22. ATAPI RESET supported in hardware, per SFF 8020i v. 1.2

Recommended

23. PCI IDE bus mastering compliant with SFF 8038i

Recommended

24. SMART-compliant drive uses SMART IOCTL API

Optional

IDE CD-ROM Peripheral Requirements

25. Compliant with SFF 8020i v. 1.2 (or higher)

Required

26. Support multisession and compatibility forms of READ_TOC

Required

IDE Floppy Drive Peripheral Requirements

27. IDE floppy drive compliant with SFF 8020i v. 2.6

Required

IDE DVD Peripheral Requirements

28. IDE DVD compliant with SFF 8020i v. 3.0

Required


Chapter 11 SCSI

This chapter presents the requirements and recommendations for SCSI under the Microsoft Windows family of operating systems.


Overview for SCSI

SCSI is a flexible I/O bus that is used in the design of a wide variety of peripherals, including disk drives, CD-ROM drives, tape drives, scanners, and magneto-optical drives. The SCSI host adapter is the circuitry that serves as an interface between the system and one or more SCSI peripherals. A host adapter can be a card that plugs into the system's expansion bus, such as a PCI card, or it can be designed directly into the system board.

The Plug and Play SCSI Specification lists the requirements for SCSI devices that create an easy-to-use environment for the user. In addition, enabling or disabling the termination on peripherals and other variables that require physically changing peripherals must be as simple as possible for the user.

The use of SCSI in a PC 97 system is optional, but if SCSI is used, all components must comply with the requirements defined in this chapter.


SCSI Host Adapter Requirements

This section summarizes SCSI class specifications and standards for SCSI host adapters.

1. Primary host controller supports bus mastering, if SCSI is present

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Required

The primary host controller should support bus mastering. For Basic PC 97, this will become a requirement in 1998.

2. Support Int 13h Extensions in option ROMs

Required

The Int 13h Extensions ensure correct support for high-capacity drives, consistent drive-letter mapping between real and protected mode, and other capabilities for both Windows 95 and future versions of Windows NT. Support for the "fixed disk access" subset of Int 13h Extensions must be provided in the system BIOS and in any option ROMs for storage devices that include BIOS support. The Int 13h Extensions are defined in "Int 13h Extension APIs" in the Layered Block Device Drivers section of the Windows 95 DDK.

3. Support virtual DMA services in option ROM, if bus mastering is supported

Required

Plug and Play SCSI host adapters that support bus mastering must support virtual DMA services (VDS) in the host-adapter option ROM. VDS supports scatter/gather capabilities, solving the problem of mapping linear addresses (segment: offset) into physical addresses. VDS is not applicable to host adapters that do not use bus mastering.

4. Bus type clearly indicated for all adapters, peripherals, and terminators

Required

Each SCSI adapter, peripheral, and terminator must be clearly marked to show the bus type. All external SCSI connectors must display the SCSI icon defined in SPI Annex F (and shown in Appendix A of this guide).

5. Differential devices support DIFFSENS as described in SCSI-3

Required

This requirement is especially important to PC systems running Windows NT. Without DIFFSENS, the differential bus drivers and/or a single-ended device will burn up if a single-ended device is put on a differential bus.

The specification for DIFFSENS is defined in section 5.4.2 of Small Computer Interface (SCSI-3) Parallel Interface (SPI) [X3T9.2].

6. Automatic termination circuit, per SCSI-3 standards

Required

SCSI implementations must use automatic termination that allows a user to add external devices without removing the PC case. Terminators used in the SCSI host adapter must be regulated terminators (also known as active, SCSI-3 SPI, SCSI-2 alternative-2, or Boulay terminators).

7. SCSI terminator built onto internal cables, per SCSI-3 standards

Required

For SCSI subsystem configurations, internal cables must be preconfigured with active termination at one end of the cable.

For device bays that have a SCSI bus built in, the terminator can be on the back plane rather than on the cable.

8. Supply terminator power to the SCSI bus, with overcurrent protection

Required

For system-board implementations using PCI or another expansion bus, the host adapter must supply terminator power (TERMPWR) to the SCSI bus. All terminators on the host adapter as well as on the internal and external SCSI bus must be powered from the TERMPWR lines in the SCSI bus.

Devices that provide TERMPWR must also provide some means of current limiting, such as a fuse or other protective device. For example, a positive-temperature-coefficient device or a circuit breaker can be designed into the circuit. These devices open during an overcurrent condition and close after the condition ends.

This item is a recommendation for battery-powered systems that implement the SCSI host adapter as a PC Card device, because of battery power consumption issues.

9. High-density external connector meets SCSI-2 standards

Recommended

If an external connector is implemented, it should be a high-density connector and must meet SCSI-2 standards.

10. Internal terminator close to last peripheral on the cable

Recommended

The internal terminator should be as physically close as possible to the last peripheral on the cable. There should be some means, such as written instructions on the cable, to ensure that the user always plugs in internal peripherals starting with the plug closest to the terminator.


Plug and Play for SCSI Host Adapters and Peripherals

This section summarizes the Plug and Play requirements for SCSI devices.

11. All components comply with Plug and Play SCSI specifications

Required

Each component must comply with Plug and Play SCSI Specification 1.0 and the related Plug and Play host bus specification (for example, PCI v. 2.1 if the PCI bus is used).

Notice, however, that the SCAM specification is optional, not required.

12. Plug and Play device identifier

Required

  • For a system board device, there must be a Plug and Play device-specific ID.
  • The device must provide device identifiers as defined in the Plug and Play SCSI Specification.

13. Automatic resource assignment and dynamic disable capabilities

Required

For peripheral devices, the system must be capable of automatically assigning, disabling, and relocating the resources used by this device when necessary. Changing or adding this device to the system must not require changing jumpers or switches on either the adapter or the system board. In the event of an irreconcilable conflict with other devices for assigning resources, the operating system must be able to disable the device to prevent the system from stalling.

14. Flexible resource configuration for each non-PCI device

Required

If the host adapter uses a non-PCI bus such as an ISA bus, the SCSI host adapter must be capable of supporting the following minimum resource configuration options:

  • Support 2 I/O locations

    Recommended: 7 I/O locations

  • Support 4 IRQ signals

    Recommended: 7 IRQ signals

  • Support 3 DMA channel selections, if DMA is used

If the minimum resource requirements cannot be met, then IRQ sharing must be implemented, as specified in the "ISA" chapter in Part 3 of this guide.


Power Management for SCSI Devices

This section summarizes the specific power management requirements for this bus class. Power management requirements for specific device classes are defined in the related chapters in Part 4 of this guide.

15. Power requirements for bus and device

Required

Additional power management requirements are specified based on industry-defined standards for the bus used by the controller and for the device. For information, see the chapter for the related bus class in Part 3 in this guide. See also the chapter for the related device class for requirements based on compliance with "Device Class Power Management Reference Specification"; for example, see the "Storage and Related Peripherals" chapter in Part 4 for power management requirements for disk drives.

16. Implement the STOP/START UNIT command as defined in SCSI-2

Required

The hardware in SCSI peripherals must be able to fully recover from a software-initiated spin-down without rebooting the system or cycling power. To properly support power management on SCSI drives, be sure to implement the STOP/START UNIT command correctly as specified in SCSI-2 to ensure that the operating system responds to appropriate driver calls.


Design Features for SCSI Peripherals

This section summarizes requirements related to specifications and standards for SCSI peripherals.

17. SCSI bus parity signal defined in the SCSI-2 specifications

Required

All SCSI peripherals must implement the SCSI bus parity signal defined in the SCSI-2 specification.

18. Cables conform to requirements in clause 6 of SPI specification

Required

Clause 6 of the SPI specification defines the various characteristics of cables for SCSI devices. See Small Computer Interface (SCSI-3) Parallel Interface (SPI) [X3T9.2/91-10].

19. User cannot plug in cables incorrectly for internal connections

Required

For an internal configuration, one end of the internal SCSI bus cable is plugged into a shrouded or keyed connector on the host adapter, which ensures that the cable is positioned properly. This connector must comply with the SPI specification.

20. Internal SCSI peripherals do not terminate the SCSI bus

Required

SCSI peripherals must not terminate the bus. Both internal and external cable ends are instead terminated by plug-in connectors. The requirement for automatic termination on the host adapter, as specified in the "SCSI Host Adapter Requirements" earlier in this chapter, ensures that the user is able to connect combinations of peripherals easily.

A design in which termination for peripherals can be set by jumpers or switches or by changing resistor packs is not acceptable for the "Designed for Microsoft Windows" logo.

21. External connectors use automatic termination or accessible onboard termination switch

Required

The preferred implementation for an external SCSI peripheral device is to provide automatic termination. In the absence of automatic termination, an external pluggable terminator must be connected to the last open device connector on the bus. If a mechanical means is provided for setting termination, the switch must be accessible to the user without opening the PC case.

22. High-density, shielded device connector meets SCSI-2 standards

Recommended

If a high-density connector is used, it must meet SCSI-2 standards.

23. Removable SCSI devices support for Media Status Notification Specification for SCSI and ATAPI Devices

Required

The Microsoft specification for Media Status Notification Support for SCSI and ATAPI Devices (v. 1.0 or higher) defines the protocol for removable SCSI devices to use in communicating about the current state of removable media.


References for SCSI

This section lists some of the publications, services, and tools available to help build hardware that work with Windows operating systems.

Plug and Play SCSI Specification

http://www.microsoft.com/hwdev/pnpspecs.htm

Media Status Notification Support Specification for SCSI and ATAPI Devices

http://www.microsoft.com/hwdev/specs/

Small Computer Interface (SCSI-2) [X3T9.2-375R]
Small Computer Interface (SCSI-3) Parallel Interface (SPI) [X3T9.2/91-10]

Global Engineering Documents
15 Inverness Way East
Englewood, CO 80112-5704
Phone: (800) 854-7179
Outside U.S. and Canada: (303) 792-2181
Fax: (303) 397-2740
ftp://ftp.symbios.com/pub/standards/io/x3t10.1


Checklist for SCSI

Basic PC 97 Workstation PC 97 Entertainment PC 97


SCSI Host Adapter Requirements

1. Primary host controller supports bus mastering, if SCSI is present

Recommended Required Required

2. Support Int 13h Extensions in option ROMs

Required

3. Support virtual DMA services in option ROM, if bus mastering is supported

Required

4. Bus type clearly indicated for all adapters, peripherals, and terminators

Required

5. Differential devices support DIFFSENS as described in SCSI-3

Required

6. Automatic termination circuit, per SCSI-3 standards

Required

7. SCSI terminator built onto internal cables, per SCSI-3 standards

Required

8. Supply terminator power to the SCSI bus, with overcurrent protection

Required

9. High-density external connector meets SCSI-2 standards

Recommended

10. Internal terminator close to last peripheral on the cable

Recommended


Plug and Play for SCSI Host Adapters and Peripherals

11. All components comply with Plug and Play SCSI specifications

Required

12. Plug and Play device identifier

Required

13. Automatic resource assignment and dynamic disable capabilities

Required

14. Flexible resource configuration for each non-PCI device

Required


Power Management for SCSI Devices

15. Power requirements for bus and device

Required

16. Implement the STOP/START UNIT command as defined in SCSI-2

Required


Design Features for SCSI Peripherals

17. SCSI bus parity signal defined in the SCSI-2 specifications

Required

18. Cables conform to requirements in clause 6 of SPI specification

Required

19. User cannot plug in cables incorrectly for internal connections

Required

20. Internal SCSI peripherals do not terminate the SCSI bus

Required

21. External connectors use automatic termination or accessible onboard termination switch

Required

22. High-density, shielded device connector meets SCSI-2 standards

Recommended

23. Removable SCSI devices support for Media Status Notification Specification for SCSI and ATAPI Devices

Required


Chapter 12 PC Card

This chapter presents requirements and recommendations for PC Card 16 (previously referred to as PCMCIA cards) and CardBus under the Microsoft Windows family of operating systems.


Overview for PC Card

Windows supports PC Card I/O cards. Memory PC Cards are only supported as legacy devices. For any PC Card device to work effectively with Windows, the manufacturer must implement a minimum set of tuples documented in the PC Card Standard. Windows uses these tuples to identify and configure any PC Card.

For PC 97, the new design concerns for PC Card are the following:

  • New design guidelines for CardBus host controllers and cards.
  • New power management guidelines, including requirements for the PC Card controller to meet new PCMCIA class power-management specifications being developed as part of the OnNow design initiative.

These new design details are discussed in this chapter.

Note Because CardBus implementations are just beginning, additional requirements might arise. As implementation details become available, Microsoft will provide information about revisions to the hardware requirements and recommendations at http://www.microsoft.com/hwdev/.


PC Card Basic Requirements

This section summarizes the basic standards for PC.

1. All devices compliant with the PC Card Standard released February 1995

Required

Designs for PC Card socket controllers, host controllers, and cards must all be based on the PCMCIA standards.

The February 1995 PC Card Standard adds requirements for minimum card information structure (CIS), 3.3v cards, multifunction cards, and cards that use DMA, and it introduces requirements for 32-bit PC Cards (CardBus). All PC Card devices must comply with these standards for PC 97.


PC Card Socket Controllers

This section summarizes PC Card requirements and standards for socket controllers.

2. Support the Industry-standard ExCA base-register set

Required

The built-in PC Card 16 software in Windows includes drivers for the Industry-standard ExCA – compatible socket controllers. To be compatible with these drivers, socket controller implementations must support the Industry-standard ExCA base-register set. Notice that some controllers do not fully implement the base-register set and are incompatible. Also, some controllers implement extended registers or enhancements. The built-in Windows drivers do not exploit these features, even though the controller might be compatible.

3. Maintain mapping of IRQ Routing Register bits to system interrupt vectors

Required

The system design must maintain the mapping of the PC Card controller's IRQ Routing Register bits to system interrupt vectors. This means that when an interrupt is programmed in the controller to occur on the IRQx pin, the system's IRQ routing causes the interrupt controller to generate the interrupt vector for IRQx, and no other IRQ.

4. Support the industry-standard definition for CardBus bridges

Required

If the system supports CardBus, it must support the definition in "PCI to PCMCIA CardBus Bridge Register Description" ("Yenta" specification) for CardBus controllers (PCI-to-CardBus bridges). This definition includes a common PCI configuration space header assigned the Header Type field value of 82H. Although this is not yet incorporated into the PCI standard, Windows supports it. Any controller features that are not part of the "Yenta" specification will not be used in standard drivers. Any hardware-initialization or setup required to make the controller comply with "Yenta" or the other requirements listed here are the responsibility of the BIOS.

Because CardBus host controllers are PCI bus bridges, they will be supported (enumerated and configured) by the PCI software in Windows in the same manner as other PCI bus bridges. For information, see the "PCI" chapter in Part 3 of this guide.

5. Support both ISA and PCI interrupts on CardBus controllers

Required

The PC Card software will dynamically configure the bridge to utilize ISA interrupts for PC Card 16 cards, and use PCI interrupts for CardBus cards. Notice the requirement to "maintain mapping of IRQ routing" earlier in this section also applies to CardBus controllers. Also notice that systems implementing CardBus controllers must fully support PCI v. 2.1 and the additional PCI requirements for IRQ routing described in the "PCI" chapter in Part 3 of this guide.

6. BIOS initializes CardBus controller in 82365-compatible mode and reports it as PNP0E03 for backward compatibility

Recommended

CardBus host controllers are enumerated and configured in Windows 95, just as other PCI bus bridges. The PCI bus bridge support in Windows 95 is based on new requirements for PCI interrupt routing and bridge-window configuration. Because of this, full compliance with the latest PCI requirements is required for CardBus support.

For backward compatibility with Windows 95, there are steps the BIOS can take. Specifically, the BIOS must initialize the CardBus controller in Intel 82365-compatible mode and report it as device "PNP0E03, Intel 82365-compatible CardBus controller." Specifically, the requirements are as follows for BIOS POST time (CardBus controller ConfigSpace initialization):

  • Command register (that is, offset 0x04) set to 0x07 (that is, IOSpaceEnable, MemSpaceEnable, BusMasterEnable).
  • RegisterBaseAddress (that is, offset 0x10) set to 0.
  • All memory and I/O windows set to 0 (that is, offset 0x1c – 0x38).
  • Interrupt Line register (that is, offset 0x3c) set to 0xff (no IRQ is assigned).
  • LegacyBaseAddress (that is, offset 0x44) set to legacy mode I/O base address (such as 0x3e0).
  • Other controller-specific initialization required to put the controller in legacy mode.

This puts the CardBus controller into Legacy mode where Socketsv.vxd (the Windows 95 Socket Services driver) can access it as an Intel PCIC-compatible controller at an I/O address (for example, 0x3e0).

Notice that the BIOS must be at least PCI 2.1 compliant, meaning that it must at least support BIOS function (AX=0xb10e) GetIRQRouting and return the necessary PCI IRQ routing information, including the routing information for the CardBus controller. In general, if the CardBus controller is on the system board, there must be a slot routing entry for it in the table. If the CardBus controller is a PCI add-on card, there must be routing information entries for each PCI slot in the system.

During Plug and Play BIOS enumeration, the BIOS should report the CardBus controller as *pnp0e03 with a compatible ID of *pnp0e00 and the I/O resource of two ports (for example, 0x3e0 – 0x3e1). Windows 95 does not know about *pnp0e03, but it does know about *pnp0e00, so it will load Socketsv.vxd (for generic Intel PCIC-compatible controllers) and everything will work with the above BIOS initialization. The Windows 95 PCI enumerator (Pci.vxd) does not know about the CardBus controller's PCI header (Type 2), so it will not report the CardBus controller device at all.

In Windows 95, when the BIOS enumerator sees *pnp0e03, it will hide the device and call the BIOS to disable it. When the BIOS receives the disable call for *pnp0e03, it should do the following:

  • Command register (that is, offset 0x04) set to 0.
  • RegisterBaseAddress (that is, offset 0x10) set to 0.
  • Interrupt Line register (that is, offset 0x3c) set to 0xff.
  • LegacyBaseAddress (that is, offset 0x44) set to 0.
  • Other controller-specific initialization required to put the controller in CardBus mode.

7. Writable PCI Configuration Space bits not shared by CardBus controllers

Required

CardBus controllers are multifunction PCI devices, and Windows treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits (such as the Command register).

Notice that the PC Card 16-bit Interface Legacy Mode Base Address Register (offset 44h in the Type 2 PCI header) is the only exception to this requirement. This register must be shared between the two functions, as they must share the same registers for compatibility with the ExCA programming model.

8. Each R2 memory window in CardBus controller has it own page register

Required

For complete flexibility and support for typical configurations, CardBus controllers must support the independent location of R2 memory windows anywhere in the full system address space as recommended in the Industry-standard "Yenta" specification. Controllers that share a single page register among all R2 memory windows place the constraint on the system that all R2 memory windows must be located within the same 16-MB block. This is often not possible with typical DRAM (16 MB) and bridge (positive decode) configurations, and consequently will result in the disabling of cards in these cases.


Plug and Play Design for PC Card 16

This section summarizes the Plug and Play requirements for PC Card 16 cards.

The Windows operating system determines what type of card is plugged into the PC Card socket by examining the tuples on the card. For Plug and Play functionality, PC I/O cards must support a set of required information and configuration tuples. The PCMCIA bus enumerator uses these tuples to identify the card, load the correct device driver, and indicate all the possible configurations to the Plug and Play configuration manager. The configuration manager then dynamically assigns a valid configuration based on this information.

9. Required I/O card tuples supported

Required

You must implement the following items for any PCMCIA I/O card that connects to a PC 97 system:

  • The PC Card must contain the device information tuple (CISTPL_DEVICE, 01h), the level 1 version/product information tuple (CISTPL_VERS_1, 15h), the configuration tuple (CISTPL_CONFIG, 1Ah), and the configuration table entry tuple (CISTPL_CFTABLE_ENTRY, 1Bh).
  • The level 1 version/product information tuple must contain the name of the manufacturer and the name of the product in the product information string (TPLLV1_INFO, byte 4).
  • The name of the manufacturer and the name of the product in the level-1 version/product information tuple must be composed only of ASCII characters greater than ASCII 20h and less than ASCII 7Fh.

Windows uses the information contained in the required and recommended tuples to create a unique device identifier for the card and to assimilate configuration information for the device. Windows uses the device configuration tuples to determine the general characteristics of the card.

Required I/O Card Tuples

Tuple
identifier 		Tuple code Description and comments

01h | CISTPL_DEVICE | Device information (common memory). For non-memory cards, this tuple must be present, but the device type will be NULL.
15h | CISTPL_VERS_1 | Level 1 version/product information: Product information string Product name Product number Other manufacturer information
1Ah | CISTPL_CONF | Configuration. Indicates the location of configuration registers and the registers present.
1Bh | CISTPL_CE | Configuration table entry. Appropriate configuration requirements for I/O space, interrupts, memory, and so on should be specified.
20h | CISTPL_MANFID | Manufacturer identifier. Card manufacturer identifier code. Defines manufacturer for this card.
21h | CISTPL_FUNCID | Function identifier. Provides function information about the card. Also includes system initialization information.

The device information tuple provides information about the memory devices used in the card's common memory space. The device type, size, and speed are used to configure the socket for efficient access to the card. This tuple must be present on PCMCIA I/O cards, but the device type must be NULL.

The Level 1 version/product information tuple contains human-readable information about the product and its manufacturer. This information is intended to be displayed to the user, where necessary. Windows uses the information contained in the product information and product name strings to construct the device identifier for that card. It also scans through the tuple, starting at the very beginning and going to the end of the product name string. The information gathered from the scan is one source for creating a 16-bit cyclic redundancy check (CRC) that Windows uses to construct the device identifier. Because the optional third and fourth strings in the tuple are not used in the CRC scan, devices that require unique numbers on each card can use these strings to store that information.

The configuration tuple tells the software where to locate the configuration registers that program the card's configuration, as well as which registers are present on the card.

Each configuration table entry tuple completely describes one valid configuration in which the card can operate. Each entry describes power, timing, I/O space, interrupt, and memory space requirements for the given configuration. Configuration software selects one of these configurations for the card based on the resources currently available in the system.

The manufacturer identifier tuple (CISTPL_MANFID, 20h) and the function identification tuple (CISTPL_FUNCID, 21h) add extra flexibility to a PC Card that connects to the PC:

  • The manufacturer identifier tuple provides unique information about the manufacturer of this card. This code is registered with PCMCIA. Windows uses the manufacturer identifier tuple as one source for creating a 16-bit CRC used in the construction of the device identifier.
  • The function identification tuple provides information about the class of device or what function the card provides (for example, memory, modem, disk, and so on). This information helps the software perform necessary installation tasks and locate compatible drivers. Although it is not required to make this determination, Windows uses the function identification tuple internally to determine what type of device is on the PC Card.

10. Configuration entry tuples listed in priority order

Required

Place the configuration entry tuples in the preferred order for configuring the device. Windows processes the tuples in the order they are placed in the card's information structure (CIS). From these tuples, Windows creates logical configuration in this order and prioritizes them in the same order. Notice that for multiple voltage cards the voltage policy is to prioritize 3.3V configurations (if supported by the system) over 5V configurations, regardless of the order of the configuration table entry tuples (CISTPL_CFTABLE_ENTRY).

11. Maximum configuration options specified

Required

Many older PC Cards specified "fixed" configurations to address compatibility with existing software. However, this is not the intended use for tuples; the configuration software should be responsible for compatibility. The tuples should be used only to rule out configurations not supported by the hardware. If you must provide fixed configurations for an operating system other than Windows, you must still provide one or more entries that specify the maximum configurability the hardware can handle.


Plug and Play Design for CardBus

This section summarizes the Plug and Play requirements for CardBus cards. CardBus was designed as a combination of PC Card 16 and PCI. The goal is to gain the benefits of PCI in the PC Card format. Consistent with this goal, Windows support for CardBus places specific requirements on CardBus cards.

12. Configuration space meets the Common Silicon Guidelines

Required

The standard for CardBus defines a PCI-like configuration space that is not fully compliant with the PCI specification. Specifically, under the CardBus Standard, card vendors do not have to implement certain critical fields in the configuration space (described in the PC Card Standard as "allocated"). In the PC Card Standard Guidelines for silicon common to both PCI and CardBus products, the implementation of these fields is recommended.

However, to maintain compatibility with existing PCI system software and drivers for PC 97, Windows will support only CardBus cards whose configuration space is designed to meet the Common Silicon Guidelines.

This is required because CardBus configuration is performed by the PCI software, which knows how to deal with all aspects of PCI topology configuration, including bridging. Without the "allocated" fields, the cards cannot be treated fully as PCI devices and therefore cannot be supported under Windows.

The required "allocated" fields are listed in the following table.

Required "Allocated" Fields

Field | Description and comments
Vendor ID | This read-only field contains a Unique ID (in PCI space) for the manufacturer of the card. It is allocated by the PCI SIG.
Device ID Revision ID | These read-only fields are vendor-assigned values that uniquely identify the device (among all vendors of PCI or CardBus products).
Class Code | These read-only fields are defined in the PCI 2.1 specification. They describe what type of device this card is.
Max_Lat Min_Gnt | These read-only fields specify the desired settings for Latency Timer values, according to the PCI 2.1 specification. Values of 0 indicate the device has no major requirements for the settings of Latency Timers.
Interrupt Line | This register must be read-write and must not be connected to anything, just as on PCI cards. This register is used to store the current IRQ routing for the device.

13. RESERVED fields compliant with PCI v. 2.1

Required

The CardBus specification also lists two fields as RESERVED (offset 2C in the configuration space), which have since been defined in the PCI v. 2.1 specification. These are also required on CardBus cards for Windows compatibility.

Required RESERVED Fields

Field | Description
SubSystem ID | If different from Device ID
SubSystem Vendor ID | If different from Vendor ID

14. CardBus required and recommended tuples implemented

Required

For CardBus, Windows also requires the same set of card tuples as recommended in the PC Card Guidelines, as summarized in the following table.

Required Tuples for CardBus

Tuple identifier | Tuple code | Comments
04h | CISTPL_CONFIG_CB |
05h | CISTPL_CFTABLE_ENTRY_CB |
07h | CISTPL_BAR |
13h | CISTPL_LINKTARGET | Required as first tuple by PC Card Standard
15h | CISTPL_VERS_1 |
20h | CISTPL_MANFID |
FFh | CISTPL_END | Required as end-of-chain tuple by PC Card Standard
21h | CISTPL_FUNCID | Recommended in PC Card Standard; required for PC 97

15. Writable PCI Configuration Space bits not shared by CardBus controllers

Required

CardBus controllers are multifunction PCI devices, and Windows treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits (such as the Command register).

For more information requirements related to the PCI Configuration Space, see the "PCI" chapter in Part 3 of this guide.


PC 97 Requirements for PC Card

This section summarizes additional PC 97 Hardware Design Guidelines.


Power Management for PC Card

This section summarizes the specific power management requirements for PC Card. Power management requirements for specific device classes are defined in the related chapters in Part 4 of this guide.

16. Compliance with "Device Class Power Management Reference Specification" for PC Card controller

Required

The "Device Class Power Management Reference Specification" for the PC Card Controller Device Class provides class-specific definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class (for example, whether a card insertion should wake the system).

17. PC Card 16 cards implement power-related events using the ReqAttn bit and the #STSCHG mechanism

Required

Any PCMCIA 5.0 card capable of signaling a Wakeup event to the system (as defined in the Device Class Power Management Reference Specification for its class) must implement the ReqAttn bit in the Extended Status register, its associated enable bit, and signaling on the #STSCHG line. PCMCIA 2.x cards must conform to the ExCA wakeup specification using but 4 of the Card Configuration and Status register to enable wakeup. Also, any card with a battery must support the Battery Voltage Detection (xBVDn) bits in the Pin Replacement register as currently defined in the PC Card Standard, and must support signal changes using the #STSCHG mechanism.

18. CardBus controllers and cards implement PCI power management specifications

Required

PCI-to-CardBus bridges and CardBus cards must conform to the requirements for power management on the PCI bus.

For information about PCI power management specifications, see the "PCI" chapter in Part 3 of this guide.

19. ZV-compatible PC Cards compliant with the PC Card standard definitions for Zoomed Video

Required

The PC Card Standard defines the requirements for ZV cards.


Device Drivers and Installation for PC Card

This section summarizes requirements for device drivers for PC Card.

20. No user intervention required for correctly installing devices

Required

The user must not be required to perform any action other than to insert disks that contain drivers and other files.

21. Device functional immediately without restarting the system

Required

The user must not have to restart the system to be able to begin using the device, either after installation is complete or whenever the device is inserted in the system.

22. ZV-compatible PC Card driver uses DirectDraw Live Video Extensions

Required

ZV-compatible PC Card drivers must use software interfaces based on 32-bit DirectDraw Live Video Extensions (LVE) to configure the graphics controller to receive video input using the ZV Port. This includes programming the graphics controller to configure the format of the video data, its location on screen, and so on. LVE is part of DirectX 3.0.

ZV card device drivers must handle dynamic graphics state changes, such as resolution changes, color depth changes, and switching to and from full-screen MS-DOS – based applications.


References for PC Card

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

PC Card support in Windows 95

http://www.microsoft.com/hwdev/busbios/

Windows 95 DDK

MSDN Professional membership

Microsoft diagnostic utility for PC Card

Microsoft provides a diagnostic utility that supports multiple voltage cards, MFC cards and the new Device ID mechanism. This utility — Dtpl.exe — is posted on the Microsoft FTP and web servers.

"Yenta" specification: PCI to PCMCIA CardBus Bridge Register Description

Published by Intel Corporation, available to all "Yenta" members.
Phone: (800) 879-4683

PCMCIA Standards

Personal Computer Memory Card International Association
2635 North First Street, Suite 209
San Jose, CA 95134 USA

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm


Checklist for PC Card


PC Card Basic Requirements

1. All devices compliant with the PC Card Standard released February 1995

Required


PC Card Socket Controllers

2. Support the Industry-standard ExCA base-register set

Required

3. Maintain mapping of IRQ Routing Register bits to system interrupt vectors

Required

4. Support the industry-standard definition for CardBus bridges

Required

5. Support both ISA and PCI interrupts on CardBus controllers

Required

6. BIOS initializes CardBus controller in 82365-compatible mode and reports it as PNP0E03 for backward compatibility

Recommended

7. Writable PCI Configuration Space bits not shared by CardBus controllers

Required

8. Each R2 memory window in CardBus controller has it own page register

Required


Plug and Play Design for PC Card 16

9. Required I/O card tuples supported

Required

10. Configuration entry tuples listed in priority order

Required

11. Maximum configuration options specified

Required


Plug and Play Design for CardBus

12. Configuration space meets the Common Silicon Guidelines

Required

13. RESERVED fields compliant with PCI v. 2.1

Required

14. CardBus required and recommended tuples implemented

Required

15. Writable PCI Configuration Space bits not shared by CardBus controllers

Required


PC 97 Requirements for PC Card

Power Management for PC Card

16. Compliance with "Device Class Power Management Reference Specification" for PC Card controller

Required

17. PC Card 16 cards implement power-related events using the ReqAttn bit and the #STSCHG mechanism

Required

18. CardBus controllers and cards implement PCI power management specifications

Required

19. ZV-compatible PC Cards compliant with the PC Card standard definitions for Zoomed Video

Required

Device Drivers and Installation for PC Card

20. No user intervention required for correctly installing devices

Required

21. Device functional immediately without restarting the system

Required

22. ZV-compatible PC Card driver uses DirectDraw Live Video Extensions

Required


Chapter 13 Serial, Parallel, and Wireless Support

This chapter presents requirements and recommendations for serial and parallel ports and wireless capabilities under the Microsoft Windows family of operating systems.


Overview for Serial, Parallel, and Wireless Support

This section presents the key design issues for serial and parallel ports and wireless capabilities for PC 97 systems.

  • System designers are encouraged to consider solutions such as USB rather than traditional serial and parallel ports for connecting external devices.
  • For optional wireless support, system designers can consider either infrared (IR) or radio frequency (RF) solutions. If both IR and RF wireless solutions are implemented in a PC 97 system, the system designer must ensure that the system correctly differentiates command streams.


System Requirements for Serial, Parallel, and Wireless Support

This section summarizes the requirements for serial and parallel ports in PC 97 system designs.

1. Connection for external serial devices

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Recommended: USB or PC Card. This capability can also be provided as a 16550A serial port or equivalent I/O capabilities provided in the system. If a legacy serial port is implemented in a PC 97 system, it must meet the requirements defined in this chapter. If two legacy serial ports are implemented, additional requirements are defined.

2. Connection for external parallel devices

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Recommended: USB, IEEE 1394, or PC Card. This can also be provided as a parallel port with Extended Capability Port (ECP) mode capabilities. If a legacy port is implemented in a PC 97 system, it must meet the requirements defined in this chapter.

3. Wireless capabilities in PC system

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

Wireless capabilities can be provided as built-in capabilities in the system or by using PC Card, IEEE 1394, or USB. If wireless capabilities are included in the system, PC 97 requirements must be met as defined in this chapter.


PC 97 Design Features for Ports

This section summarizes requirements related to the design initiatives for PC 97 defined in Part 1 of this guide.


Plug and Play and Bus Design for Ports

The items in this section are requirements for Plug and Play capabilities.

4. Plug and Play device identifier

Required

  • For a non-bus-specific system board device, there must be a device-specific identifier.
  • Each bus-specific device must have a Plug and Play device identifier as required for the bus it uses, as defined in Part 3 of this guide. For example,
    a PCI device must comply with PCI 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide.

5. Automatic resource assignment and dynamic disable capabilities

Required

The system must be capable of automatically assigning, disabling, and relocating the resources used by this device when necessary, using the method required for the related bus class. Changing or adding this device to the system must not require changing jumpers or switches on either the adapter or the system board. In the event of an irreconcilable conflict with other devices on the system, the system must be able to disable the device to prevent the system from stalling.

If there is a conflict when more than one port or device of the same type is detected on the system, one of two methods can be used to resolve them:

  • The first method is to completely disable the built-in port or device. For example, if there is a conflict when a second serial port is added to a desktop system, the expansion card overrides the system board device. Using this method, the system disables the device on the system board and only enables the expansion card. This is the recommended method for conflict resolution for add-on serial, parallel, MIDI, and joystick devices.
  • The second method allows both ports or devices to remain active, while resolving any conflict by relocating the resources of one or both devices. Using this method, either device can be used.


Power Management for Ports

This section summarizes the specific power management requirements for ports.

6. Compliance with Device Class Power Management Reference Specification

Required

The "Device Class Power Management Reference Specification" for the communications device class provides definitions of the OnNow device power states (D0–D3) for serial devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class. Power states D0 and D3 are required; other states are recommended.

7. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Required

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" is a required feature.


Device Drivers and Installation for Ports

This section summarizes requirements for device drivers for ports. The items in this section are requirements for all PC 97 systems.

8. Device driver and installation meet Windows and Windows NT standards

Required

The manufacturer does not need to supply a driver if a standard driver provided with the operating system can be used. If the manufacturer supplies drivers, the requirements include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry.
  • The correct minidriver, VxD, or any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations.
  • Driver installation and removal uses Windows-based methods as defined in the Windows 95 and Windows NT DDKs.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.


Serial Port Requirements

This sections summarizes the hardware design features for serial ports for PC 97.

Serial ports have been used on computers for decades. In the past, standard baud rates for most serial ports ranged up to 19.2K baud. Now that systems and peripherals have become more demanding, higher-speed devices must be used to meet the needs of the newest generation of serial ports.

9. General device requirements

Required

These include the standard requirements for a device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information see the "Basic PC 97" chapter of this guide.


Legacy Serial Port Requirements

This section defines requirements for legacy serial ports.

10. 16550 UART (or equivalent) with support for 115.2K baud

Required

A 16550A buffered UART or equivalent buffered serial port is required to support high-speed communications while reducing the CPU requirements for servicing the device. The device must be able to support 115.2K baud.

11. Flexible resource configuration and dynamic disable

Required

A legacy serial port must provide flexible resource configuration and complete dynamic disable capabilities following Plug and Play External COM Device Specification v. 1.0.

These are the recommended resource settings for non-PCI devices:

  • 4 I/O locations for each port (standard is 3F8h, 2F8h, 3E8h, 2E8h). Using the standard addresses ensures the proper functioning of software that addresses these locations directly.
  • 2 IRQ signals (standard is IRQ 3, IRQ 4). Support of the standard IRQ signals ensures the proper functioning of software written for systems that use standard IRQ signals.

Two IRQs are required for each port. If two serial ports are implemented in the system, the IRQs can be assigned as follows:

  • For serial port A: IRQ 4 and IRQ 11
  • For serial port B: IRQ 3 and IRQ 10

An infrared adapter (IR) port might replace a serial port in a system. In such a case, the IR port should use the resource configuration that would otherwise be assigned to the second serial port.

Notice that, as for all devices, IRQ sharing is required if the minimum resource requirement cannot be met.

12. Conflict resolution ensures availability of at least one serial port

Required

In the event of an irreconcilable conflict with other serial ports on the system, a serial port must be capable of being disabled by the Plug and Play software. This allows at least one of the two conflicting serial ports to operate correctly.


Requirements for Other Serial Port Implementations

This section defines requirements for non-legacy implementations to support serial port capabilities.

13. Serial port complies with device-class specifications for its bus

Required

As required for all PC 97 devices, a serial port implementation that uses a non-legacy bus must meet the specific device-class requirements for that bus.

For example, a serial port implementation that uses USB must comply with all related USB specifications, including the USB Specification 1.0 (or higher) and Universal Serial Bus Device Class Definition for Communication Devices 1.0 (or higher). The appendix titled "Standard Serial Interface Circuit Emulation" in the USB Device Class Definition for Communication Devices specifically addresses compatibility for serial ports.


Parallel Port and Peripheral Requirements

This section summarizes the basic design features for parallel ports and peripherals. Each parallel port on a PC 97 system must meet the requirements listed in this section.

14. General device requirements

Required

These include the standard requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information see the "Basic PC 97" chapter of this guide.


Legacy Parallel Port Requirements

This section defines requirements for legacy parallel ports.

15. Flexible resource configuration for each parallel port

Required

A legacy parallel port must provide flexible resource configuration following Plug and Play Parallel Port Device Specification v. 1.0b. Resource requirements must be met for each device of this type on the system. The requirements cannot be split between two ports on the system.

For non-PCI devices, these are the minimum resource requirements for each parallel port on the system:

  • Required: Support 378h, 278h, plus 3BC or a vendor-assigned I/O address. Using these standard I/O addresses facilitates proper functioning of software written for operating systems that address these locations directly.

    Recommended: Also map the base I/O address to four additional locations.

  • Required: Support IRQ 5 and IRQ 7. Use of these standard IRQs ensures proper functioning of software written for operating systems that use standard IRQ signals.

    Recommended: Support five additional IRQ signals.

  • Required: Support two unique DMA channel selections, if the parallel port design supports block data transfers to memory using the DMA controllers. Notice also that the DMA function will not work on a parallel port without an IRQ, because the end of a DMA transfer is signaled by an interrupt.

To ensure Plug and Play support for resolution of resource conflicts, a full list of options for all possible configuration combinations must be enumerated, including:

  • Options for both ECP mode (which requires an I/O address, an IRQ, and a DMA selection) and standard LPT mode (which requires only an I/O address).
  • Options that specify only the I/O address to allow Windows to assign the IRQ and DMA channel.

Windows considers the parallel port base (/) address stored in the first BDA locations to be LPT1. The address stored in the second location is LPT2, and so on.

16. I/O address restrictions for EPP support

Required

Some Enhanced Parallel Port (EPP) implementations require eight contiguous I/O ports. If EPP support is implemented, the hardware cannot use 3BCh as a base I/O address because VGA devices require use of port 3C0h.

17. Compatibility, nibble mode, and ECP protocols compliant with IEEE 1284-1994

Required

Support for a parallel port must include the compatibility mode and nibble mode protocols required by the IEEE 1284-1994 specification for minimum compliance. This allows other 1284-compliant devices to be connected without problems.

The port must also support the ECP protocol as defined by IEEE 1284 to allow connections with higher speed parallel peripherals.

18. Port connectors compliant with 1284-I, at a minimum

Required

IEEE 1284-I – compliant ports use a standard DB25 connector found on existing system parallel port designs, called a 1284-A connector in the specification.

IEEE 1284-II – compliant ports use a 1284-C connector. This connector is used on both the port and the peripheral device.

The parallel port design must provide enough space between the connectors and the surrounding enclosure to allow for a mating connector, the connector shell, and the latch assembly. The IEEE 1284 specification recommends a 1284-C connector for all new ports and devices.

19. Plug and Play device identifier for 1284 peripherals

Required

The device identifier is described fully in the IEEE 1284 specification. All characters in the device identification string must consist only of ASCII values from 20h to 7Fh. The device identification string consists of a leading zero, a hexadecimal value that represents the length of the string, and then a set of fields, in ASCII, with a unique identification string.

For PC 97, in addition to the requirements specified in the Plug and Play Parallel Port Device Specification v. 1.0b, the device-ID string must contain these keys at a minimum: MANUFACTURER (MFG), MODEL (MDL), CLASS (CLS), and DESCRIPTION (DES). The keys are case sensitive and can be abbreviated as indicated.

All MANUFACTURER and MODEL key values must remain unique from each manufacturer. All MANUFACTURER, MODEL, CLASS, and DESCRIPTION key values must remain static for a specific unit (that is, identifier values do not change for different hardware configurations). For example, a user simply adding a memory module to a printer should not change the MODEL key value reported as part of the device identifier. However, if the user adds memory by installing an upgrade kit that requires a different driver or requires the existing driver to behave differently, then changing the MODEL value is acceptable as part of the upgrade installation process.

The CLASS key describes the type of parallel device. The CLASS key can contain the values PRINTER, MODEM, NET, HDC, PCMCIA, MEDIA, FDC, PORTS, SCANNER, or DIGCAM. HDC refers to hard disk controller. MEDIA refers to any multimedia device. FDC refers to floppy-disk drive controller.

The DESCRIPTION key is an ASCII string of up to 128 characters that contains a description of the device the manufacturer wants to have presented if a device driver is not found for the peripheral.

For information about how the system determines the correct peripheral device driver, see the Windows 95 and Windows NT DDKs.

20. Support CompatibleID key in the device identification string

Recommended

The CompatibleID (CID) key can provide a value that exactly matches a peripheral name supported by a device driver shipped with Windows. The value must match a value listed in the device's INF file.


Requirements for Other Parallel Port Implementations

This section defines requirements for non-legacy implementations to support parallel port capabilities.

21. Parallel port complies with device-class specifications for its bus

Required

As required for all PC 97 devices, a parallel port implementation that uses a non-legacy bus must meet the specific device-class requirements for that bus.

For example, a parallel port implementation that uses USB must comply with all related USB specifications, including the USB Specification 1.0 (or higher) and any specific device class specification.


Wireless Component Requirements

This section summarizes the basic design features for wireless components, provided either as infrared (IR) adapters or radio frequency (RF) adapters.

Many manufacturers are implementing integrated IR solutions for mobile PCs. Various form-factor and environmental issues limit the adoption of wireless solutions for desktop PCs, including receiver placement in the office environment and methods for limiting conflicting device signals.

Microsoft recommends that manufacturers move their wireless designs to incorporate fast IR solutions as soon as possible. Fast IR transmits and receives data at speeds of 1.152 Megabits per second (Mbps) and 4.0 Mbps. Fast IR includes design implementations that improve usability. However, interoperability issues still must be addressed.

The requirements listed in this section must be met if wireless capabilities are provided in the system.

22. General device requirements

Required

These include the standard requirements for a unique Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information see the "Basic PC 97" chapter of this guide.

23. Compliance with "Device Class Power Management Reference Specification" for wireless devices

Required

The "Device Class Power Management Reference Specification" for wireless devices provides definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class. Power states D0 and D3 are required. Other states are recommended.

24. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for wireless devices is an optional feature.


IR Requirements

This section summarizes basic design features for infrared components.

25. Echo cancellation in hardware, for slow-speed IR devices

Required

A software solution is not acceptable. Echo cancellation must be supported in the hardware.

26. NDIS 4.0 miniport driver for IR devices

Required

An NDIS 4.0 IrDA miniport driver is required for all IR devices. Full documentation and sample source code for building such a miniport driver is in the Windows NT 4.0 DDK.

27. System supports 4 megabits per second standard for input

Recommended

Device support for input speeds of 4 Mbps is strongly recommended.

28. System supports both IrDA and consumer IR remote control devices

Recommended

If the system is intended to run data transfer applications, support of the IrDA specifications is required. If the system is intended for the home market, support for consumer IR technology is also recommended. A combination chip set that supports both IrDA and consumer IR technology is recommended for all systems.

29. System differentiates command streams if both IrDA and remote control devices are supported

Required

This requirement ensures correct implementation for a system that includes IR support for both IrDA codes and remote control devices that use different device signals. A system that uses only a specific remote control protocol will restrict the ability to use multiple input devices and might also restrict other capabilities.

The system needs a method for either automatically switching to alternate modes or notifying the IR driver of the need to switch modes. If the second alternative is used, then the device manufacturer must publish the hardware interface the software can use for mode switching.

30. System supports a minimum range of 3 meters if both IrDA and remote control devices are supported

Recommended

The minimum IrDA device range that must be supported is 1 meter, but the home user is expected to use remote control devices at ranges greater than that.

31. Unicast filtering, for high-speed IR device

Recommended

For future multipoint IR protocols, filtering unicast packets not directed at the receiver will optimize performance.

32. Flexible resource configuration and dynamic disable

Required

The adapter must provide flexible resource configuration and complete dynamic disable capabilities following the specifications for the bus or legacy port used. These are the recommended resource settings for non-PCI devices:

  • Support 4 unique I/O locations

    Recommended: 7 unique I/O locations

  • Support 4 unique IRQ signals

    Recommended: 7 unique IRQ signals

Notice that, as for all devices, IRQ sharing is required for ISA if the minimum resource requirement cannot be met.

33. Device compliant with bus and port specifications

Required

The requirements for all bus classes are defined in Part 3 of this guide. The Windows operating system includes built-in support for devices that use the serial I/O interface; in this case, the wireless device must also comply with the requirements specified in the "Serial Port" requirements section earlier in this chapter. A device that uses the parallel port must comply with the requirements specified in the "Parallel Port and Peripheral Requirements" section earlier in this chapter.


RF Recommendations

Radio Frequency (RF) is the preferred medium to support wireless keyboard devices and any other wireless PC peripheral used for sessions of relatively long duration or conducted at a relatively long range. In contrast, IR is the preferred medium to support devices used in point-and-shoot, ad-hoc sessions of short duration, conducted at short range.

Use of RF in cordless peripherals such as keyboards, mice, joysticks, and remote controls is attractive to users. These cordless peripherals are direct substitutes for the devices attached to the PC with cables.

Other uses of RF attractive to users are home and small-office networking, cordless telephones, and cordless audio headphones. Manufacturers are encouraged to develop low-priced, relatively short-range solutions for these markets.

Manufacturers who are implementing designs that include RF devices are strongly encouraged to communicate with Microsoft. Microsoft wants to work with manufacturers to standardize RF protocols and media within the computer industry. Please send e-mail to ihv@microsoft.com. For more information about RF alternatives, see http://www.microsoft.com/hwdev/devdes/.

34. Select a low-power RF alternative

Recommended

For relatively short-range RF devices, it is possible to use a low-power RF device. Use an RF device appropriate to the application. For example, cordless keyboard and trackball devices only need a maximum range of 15 to 20 feet.

35. Consider noise and conflict with other RF devices in the environment

Recommended

RF devices should have a way to defeat noise, such as EMI interference. Also, programmable channel selection, carrier sensing, or the relatively expensive spread-spectrum or frequency hopping techniques can be used to share the RF medium with other RF devices that might be in the environment.

36. Separate certification of the system and the RF device

Recommended

Rules for certifying low-power, short-range, unlicensed RF devices vary greatly from country to country. By configuring the RF device as a system add-on, local certification of the system will not be blocked while waiting for certification of the RF device, which might take longer. Configuring the RF device as a system add-on also enables adding RF support to legacy hardware.


References for Serial, Parallel, and Wireless Support

This section lists some resources to help build hardware that works with Windows operating systems.

Plug and Play documentation

http://www.microsoft.com/hwdev/pnpspecs.htm

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm

Windows NT DDK, Windows 95 DDK, and Infrared Communications for Windows 95 DDK

MSDN Professional membership

Infrared Data Association Serial Infrared (SIR) Physical Layer Specification

Available only to IrDA members:
Infrared Data Association (IrDA)
P. O. Box 3883
Walnut Creek, CA 94598 USA
Phone: (510) 943-6546
Fax: (510) 943-5600
E-mail: irda@netcom.com


Checklist for Serial, Parallel, and Wireless Support

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Serial, Parallel, and Wireless Support

1. Connection for external serial devices

Required Required Required

2. Connection for external parallel devices

Required Required Required

3. Wireless capabilities in PC system

Recommended Recommended Recommended


PC 97 Design Features for Ports

Plug and Play and Bus Design for Ports

4. Plug and Play device identifier

Required

5. Automatic resource assignment and dynamic disable capabilities

Required

Power Management for Ports

6. Compliance with Device Class Power Management Reference Specification

Required

7. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Required

Device Drivers and Installation for Ports

8. Device driver and installation meet Windows and Windows NT standards

Required


Serial Port Requirements

9. General device requirements

Required

Legacy Serial Port Requirements

10. 16550 UART (or equivalent) with support for 115.2K baud

Required

11. Flexible resource configuration and dynamic disable

Required

12. Conflict resolution ensures availability of at least one serial port

Required

Requirements for Other Serial Port Implementations

13. Serial port complies with device-class specifications for its bus

Required


Parallel Port and Peripheral Requirements

14. General device requirements

Required

Legacy Parallel Port Requirements

15. Flexible resource configuration for each parallel port

Required

16. I/O address restrictions for EPP support

Required

17. Compatibility, nibble mode, and ECP protocols compliant with IEEE 1284-1994

Required

18. Port connectors compliant with 1284-I, at a minimum

Required

19. Plug and Play device identifier for 1284 peripherals

Required

20. Support CompatibleID key in the device identification string

Recommended

Requirements for Other Parallel Port Implementations

21. Parallel port complies with device-class specifications for its bus

Required


Wireless Component Requirements

22. General device requirements

Required

23. Compliance with "Device Class Power Management Reference Specification" for wireless devices

Required

24. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

IR Requirements

25. Echo cancellation in hardware, for slow-speed IR devices

Required

26. NDIS 4.0 miniport driver for IR devices

Required

27. System supports 4 megabits per second standard for input

Recommended

28. System supports both IrDA and consumer IR remote control devices

Recommended

29. System differentiates command streams if both IrDA and remote control devices are supported

Required

30. System supports a minimum range of 3 meters if both IrDA and remote control devices are supported

Recommended

31. Unicast filtering, for high-speed IR device

Recommended

32. Flexible resource configuration and dynamic disable

Required

33. Device compliant with bus and port specifications

Required

RF Recommendations

34. Select a low-power RF alternative

Recommended

35. Consider noise and conflict with other RF devices in the environment

Recommended

36. Separate certification of the system and the RF device

Recommended


Chapter 14 Input Components

This chapter presents the requirements and recommendations for standard input devices and connections under the Microsoft Windows family of operating systems.


Overview for Input Components

This section presents the key design issues for input components under Microsoft Windows.

These are the key issues for input devices for PC 97:

  • Easy connectivity is important in common situations where devices might be interchanged on a regular basis. For this purpose, system designers are encouraged to take advantage of USB and to implement wireless capabilities for all input components.

    USB support is required for PC 97 systems. If USB is implemented as the connection for any input device, the device must support the USB Human Input Device Class Specification.

  • Non-USB input devices must have device drivers that support the Microsoft DirectInput 3.0 APIs. DirectInput provides low-latency support for analog and digital joysticks, along with support for alternate input devices for user interaction. Extended capabilities also provide support for rudder pedals, flight yokes, steering devices, virtual-reality headgear, and other devices.

    Non-USB input devices that provide hardware acceleration should expose these features in their device drivers, so that these capabilities can be used to advantage in applications that use Microsoft DirectX features.

  • Windows and Application Logo keys are recommended for keyboards.


System Requirements for Input Components

This section summarizes the requirements for specific input components for PC 97 system designs.

For a mobile PC system, the required USB port can be used to support the requirement for external mouse and keyboard connections. However, two PS/2-style ports can be implemented for the mouse and keyboard, or a single PS/2-style port can be provided for both the mouse or keyboard on a mobile PC.

1. External connection for keyboard

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Recommended: USB. This connection can also be implemented as a PS/2-style port or by using wireless capabilities in the system. For mobile PC systems, a single PS/2-style port can be provided for use by either the mouse or keyboard.

2. External connection for pointing device

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Recommended: USB or wireless. This connection can also be implemented using a PS/2-style port in the system.

3. Wireless capabilities

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

An infrared or radio-frequency (RF) remote-control device included with a PC system must meet the requirements defined in the "Mouse Port and Peripherals" section in this chapter and the requirements in the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

4. USB game pad or joystick

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

Recommended: Wireless for Entertainment PC 97.

This device must support the USB Human Input Device Class Specification. For more information about requirements for USB peripherals, see the "USB" chapter in Part 3 of this guide.

Note For PC 97, the recommended solution for game control input devices is to provide devices that use a USB connection rather than a proprietary or traditional game port. This is the required implementation for Entertainment PC 97.

An input device that uses a traditional or proprietary digital game port solution is not recommended for PC 97 systems and not allowed for Entertainment PC 97, because there are no defined standards for digital game ports, some digital game port designs are incompatible with some devices, and traditional game ports impose performance limitations on high-speed processors.

However, it is recognized that some legacy implementations include traditional or proprietary game port capabilities (this includes providing a MIDI port that can be used as a game control port). A system designer might choose to include such a port on a PC 97 system to allow users to connect their legacy devices. For information about PC 97 requirements related to such legacy ports, see "Legacy Game Control Port Requirements" later in this chapter.


PC 97 Design for Input Devices

This section summarizes requirements related to the design initiatives for PC 97 defined in Part 1 of this guide.


Plug and Play and Bus Design for Input Devices

The items in this section are requirements for Plug and Play capabilities.

5. Plug and Play device identifier

Required

  • For a non-bus specific system board device, there must be a device-specific identifier.
  • Each bus-specific device must provide a Plug and Play device identifier in the manner required for the bus it uses, as defined in Part 3 of this design guide. For example, a PCI device must comply with PCI 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide. A device that uses USB must provide a unique identifier as defined in the Universal Serial Bus Specification v. 1.0 or higher.

6. Automatic resource assignment and dynamic disable capabilities

Required

The operating system must be capable of automatically assigning, disabling, and relocating the resources used by this device when necessary, using the method required for the related bus class. Changing or adding this device to the PC system must not require changing jumpers or switches on either the adapter or the system board. In the event of an irreconcilable conflict with other devices, the operating system must be able to disable the device to prevent the system from stalling.

If there is a conflict when more than one device of the same type is detected on the system, one of two methods can be used to resolve them:

  • The first method is to completely disable a port. For example, if an expansion card, such as a display adapter with a built-in mouse port is added to a desktop system that has a system board mouse port, the expansion card overrides the system board mouse port. Using this method, the system disables the mouse port on the system board and only accepts mouse input from the expansion card.
  • The second method allows both ports to remain active, while resolving any conflict by relocating the resources of one or both ports. For example, in a docking system, the mouse on the mobile PC and the mouse on the docking station can be allowed to share pointing responsibilities. Using this method, either mouse can be used as a pointing device, although only one mouse pointer will be used by the software.

Note Fixed (static) resource devices can exist to support standard devices, including the keyboard controller (8042). For an x86-based system, these fixed resources are located at I/O addresses under 100h. Standard system board devices should use their ISA-compatible addresses. For x86-based systems, this includes devices with I/O port addresses within the reserved range 0h through 0ffh. For more information about legacy resources and ISA-compatible addresses, see Appendix D, "Legacy I/O Assignments."


Power Management for Input Devices

This section summarizes the specific power management requirements for input devices.

7. Compliance with "Device Class Power Management Reference Specification" for input devices

Required

The "Device Class Power Management Reference Specification" for input devices provides definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class. Power states D0 and D3 are required. Other power states are recommended.

8. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for input devices is an optional feature.


Device Drivers and Installation for Input Devices

This section summarizes requirements for device drivers for input devices. The items in this section are requirements for all PC 97 systems.

9. Device driver and installation meet Windows and Windows NT standards

Required

The manufacturer does not need to supply a driver if a standard driver provided with the operating system can be used. If the manufacturer supplies drivers, the requirements include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry.
  • The correct minidriver or any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations.

    For input devices in PC 97, the correct Win32 Driver Model (WDM) minidriver or USB Human Input Device driver plus other WDM-compatible drivers and any other files specified in the device's INF must be installed in the correct locations.

  • Driver installation and removal uses Windows-based methods as defined in the Windows 95 and Windows NT DDKs.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers).
  • If support using WDM drivers is provided on the operating system, the driver supplied by the manufacturer must be a WDM minidriver. Older Windows 95 VxD files must not be installed for PC 97 input devices that have WDM support under Windows 95 and Windows NT.

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.


Mouse Port and Peripherals

This section defines the specific requirements for pointing device connections and peripherals. Because the Windows operating system requires a pointing device, a system board in a PC 97 system should include an auxiliary port for an external pointing device (most commonly, a mouse). For PC 97, it is recommended that systems designers use the USB port for the connection and also consider implementing wireless support for an external pointing device.

10. General device requirements

Required

These include the standard requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information, see the "Basic PC 97" chapter of this guide.

11. PS/2 port specifications, if PS/2-style port is used

Required

The following requirements must be met if a PS/2-style port is used:

  • Comply in full with Personal System/2 Specification requirements published by IBM.
  • Use an 8042 chip (or equivalent) to ensure compatibility with Windows. (In most cases, the existing 8042 keyboard port is sufficient.) The 8042 initiates an IRQ 12 interrupt when the mouse is connected to the port.
  • Support IRQ 12 to enable the proper functioning of software written for
    legacy systems that expect this IRQ signal to be used.
  • Return expected codes, including send identifier (0F2h), response: ACK (0FAh) + 1-byte ID.

12. USB Specification and device class specifications, if USB is used

Required

This device must comply with the Universal Serial Bus Specification v. 1.0 or higher, and the related USB device class specification. This ensures that all Plug and Play requirements are met and that Microsoft drivers support this device. For more information, see the "USB" chapter in Part 3 of this guide.

13. IR wireless specifications, if IR device is used

Required

An infrared device must support IrDA codes and all other requirements specified in the IrDA specification.

14. RF wireless specifications, if RF wireless device is used

Recommended

Numerous consumer electronics remote controls use proprietary RF communications protocols to provide low-cost, one-way remote control functionality, often at relatively great distances (up to 10 meters).

For more information about support and standards being developed at Microsoft for RF devices, see http://www.microsoft.com/hwdev/devdes/.

15. Remote control provides minimum support, if present

Recommended

The range of functions implemented on the remote control device will depend on whether the remote control is designed for the business desktop or for Entertainment PC 97 use. There is no defined list of the functions that must be included on a remote control device, but such a device might provide the following types of functions and buttons:

  • Power button that turns devices on and off
  • Start button, with Windows Logo, that causes a Start menu to be displayed
  • Menu button that causes an application-specific menu to be displayed
  • Help button that causes application-specific help to be displayed
  • South, North, East, and West direction capability which functions similarly to the Down-arrow, Up-arrow, Left-arrow, and Right-arrow keys on a keyboard
  • Select button that functions similarly to the Enter key on a keyboard

The following functions and buttons can also be considered for a remote control used with an Entertainment PC 97 system:

  • TV button that selects the TV as the device with focus
  • Mute button
  • Device control buttons, including Volume Up, Volume Down, Channel Up, Channel Down, Fast Forward, Rewind, Play, Stop, Pause, and Record
  • Number keys equivalent to a telephone keypad


Keyboard Ports and Peripherals

The primary input component for a PC is the keyboard. The keyboard connection on the system board has traditionally been controlled by an 8042 microcontroller or the equivalent. However, for PC 97, USB connections and wireless connections are important design considerations for PC keyboard connections. Also, these design requirements do not exclude (but do not encourage) implementing a legacy AT-style keyboard port.

This section summarizes the specific hardware features required for PC 97 keyboard ports and peripherals. Some keyboard port requirements differ, depending on what type of port is being used.

16. General device requirements

Required

These include the standard requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information, see the "Basic PC 97" chapter of this guide.

17. PS/2 specifications by IBM and 8042 chip (or equivalent), if PS/2 used

Required

If a PS/2-style keyboard port is designed into the system, it must meet the following requirements:

  • Support IRQ 1 to ensure the proper functioning of software written for legacy systems that expect to use this IRQ signal.
  • Map the I/O address ports to 60h and 64h.

18. USB Specification and USB device class specification, if USB is used

Required

This device must comply with the Universal Serial Bus Specification (v. 1.0 or higher) and the related USB device class specification. This ensures that all Plug and Play requirements are met and Microsoft drivers support this device. For information, see the "USB" chapter in Part 3 of this guide. The keyboard must also support the USB Human Input Device Class Specification.

If a USB keyboard is the sole keyboard implementation in the system, it must support the USB Boot Device specification, and the system BIOS must provide boot support, as specified in "Basic PC 97" in Part 2 of this guide and defined in "Universal Serial Bus PC Legacy Compatibility Specification," v. 1.0 or higher, available from http://www.teleport.com/~usb/data/usb_le9.pdf.

19. Wireless specifications, if wireless device is used

Required

An IR device must support IrDA codes and all other requirements specified in the IrDA specification.

20. PS/2- style keyboard returns expected scan codes

Required

This includes send identifier (0F2h), response: ACK (0FAh) + 2-byte ID.

21. No interference between keyboards for multiple devices

Required

For example, when a mobile PC is connected to a docking station, more than one keyboard can be attached to the system simultaneously. The keyboard ports on a mobile PC and the docking station must be able to resolve conflicts between the two ports when the mobile unit is docked. Windows supports multiple configurations through the registry and will determine which keyboard to enable.

For more information about managing resources and devices for a mobile PC and docking station pair, see the "Basic PC 97" chapter in Part 2 of this guide.

22. Windows and Application Logo keys

Recommended

If the keyboard includes any Windows Logo keys, it must meet the following requirements:

  • The keyboard must be developed according to technical requirements in New Key Support for Microsoft Windows Operating Systems and Applications.
  • The keyboard must be compatible at the Windows virtual key code level.
  • The keyboard must pass the requirements in the Windows Logo Key Testing Software before being submitted to Microsoft WHQL for testing.
  • The Windows Logo key must function as a modifier key (Ctrl, Shift, or Alt).
  • The Windows Flag trademark must be clearly distinguished on the keytop per the guidelines provided in New Key Support for Microsoft Windows Operating Systems and Applications.

The following are recommendations if a keyboard design includes any Windows Logo keys:

  • Both Left and Right Windows Logo keys are not required in order to have full functionality under the Windows operating system.
  • The Application key can be a dual-function key and can be used to replace the Fn key. In this case, a single press-and-release action sends the scan code for the Application key, and holding this key down while pressing another key will modify it and perform the Fn function.
  • Given the crowded nature of compact keyboards on mobile PCs and keyboards that support double-byte characters (such as Japanese language keyboards), it might be difficult to add three new keys. For mobile PCs, minimal implementation of the new keys includes the addition of one Windows Logo key and one Application key.


PC 97 Game Pad Requirements

This section presents the minimum requirements for game control devices such as game pads for PC 97.

USB is a required port and is the recommended PC 97 solution for game input devices such as game pads, phasing out the standard DB15 game port. A proprietary "digital" game port on a PC 97 system is not recommended, because some digital joystick devices work only in analog mode with proprietary digital ports.

23. General device requirements

Required

These include the standard requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information, see the "Basic PC 97" chapter of this guide.

24. USB Human Input Device Class Specification support

Required

PC 97 game control devices and drivers must support the USB Human Input Device Class Specification v. 1.0 or higher.


Legacy Game Control Port Requirements

This section defines the minimum requirements for a legacy game control port that might be included on the system board, in an add-on card such as an audio card, or as a standalone add-on device.

For PC 97, the recommended solution for game control input devices is to provide devices that use a USB connection rather than a proprietary or traditional game port. Game controls that use traditional game ports are not acceptable solutions for PC 97, because these legacy ports impose performance limitations on high-speed processors and do not completely support Plug and Play.

However, a legacy game port can be included on a multifunction card or in a PC 97 system if the system designer wants to allow users to connect their existing legacy game control devices. In order to be eligible for the "Designed for Microsoft Windows" logo, a device or PC system that includes a legacy game port must meet the requirements defined in this section.

25. General device requirements

Required

Although it is recognized that traditional game devices do not support Plug and Play, for PC 97 it is required that the device use software-only settings for device configuration, standard device drivers, and Windows-based installation. For more information about general device requirements, see the "Basic PC 97" chapter of this guide.

26. Legacy game port complies with bus and device-class specifications

Required

If a game port uses a bus such as PCI or ISA, the port must fully comply with the specifications for the bus where it is installed. If the game port is implemented as a PCI device, it must meet all the PCI 2.1 requirements for PC 97 as defined in the "PCI" chapter in Part 3 of this guide.

27. Resource arbitration for non-PCI game port devices

Required

For devices that use expansion buses such as ISA, the following minimum resource configuration requirements must be met:

  • Use standard I/O location in the range 200 through 20FH, and correctly report a unique device node for Plug and Play enumeration.
  • Provide four unique IRQ signals, if used — that is, if IRQs are supported, then they must be mappable to seven unique IRQ signals.

Notice that, as for all ISA devices, ISA IRQ sharing is required if the minimum resource requirement cannot be met.

28. Device driver meets Windows 95 driver requirements

Required

The device driver for Windows 95 must not replace Microsoft VxDs and joystick drivers, and it must be compliant with the Windows 95 driver requirements for installable device drivers, as defined in the Windows 95 DDK.

29. Device driver for non-USB device supports DirectInput 3.0 APIs

Required

The upper edge of the device driver must support DirectInput 3.0 or higher, as defined in the Windows 95 DDK.

30. MIDI-compatible legacy port uses Sound Blaster pin-out

Required

Some legacy multifunction cards use a MIDI port as a game control port. If a MIDI port is implemented in the PC system, it must use the pin-12 and pin-15 standard and Transistor-Transistor Logic (TTL) level used in Sound Blaster-compatible designs.

31. Legacy game port works with Windows-supplied drivers

Required

The port must work unmodified with driver files provided with the Windows operating system.

32. If present, proprietary port meets PC 97 requirements

Required

If a game port is implemented as a proprietary port instead of the recommended PC 97 implementation for USB, the port must meet the following requirements:

  • The device driver must support the DirectInput 3.0 APIs.
  • The device driver for Windows 95 must not replace Microsoft VxDs and joystick drivers, and it must be compliant with the Windows 95 driver requirements for installable device drivers, as defined in the Windows 95 DDK.
  • The minidriver must be dynamically loadable and unloadable, and therefore be immediately functional without rebooting the system.

    The user must be able to go directly from installation, select the new game device from the Control Panel (or have it auto-selected by way of an installation disk), and then be available for use with any Windows 95-based game. If the device is provided with applications that require a reboot, the installation program must notify the user at the end of installation that these applications require a reboot. The installation program must then give the user the option of rebooting or returning to Windows 95.


References for Input Components

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Windows 95 DDK, Windows NT DDK, DirectX DDK

MSDN Professional Membership

IBM Personal System/2 Common Interfaces, Part No. S84F-9809
IBM Personal System/2 Mouse Technical Reference, Part No. S68X-2229

International Business Machines Corporation
IBM Customer Publications Support: (800) 879-275
Or contact an IBM sales representative

Infrared Data Association Serial Infrared (SIR) Physical Layer Specification

Available only to IrDA members:
Infrared Data Association (IrDA)
P. O. Box 3883
Walnut Creek, CA 94598 USA
Phone: (510) 943-6546
Fax: (510) 943-5600
E-mail: irda@netcom.com

New Key Support for Microsoft Windows Operating Systems and Applications

Newkeys.zip (self-extracting zip file)
ftp://ftp.microsoft.com/PerOpSys/Win_News

Windows Logo Key testing software, documentation, and license agreement

http://www.microsoft.com/hwtest/
The license agreement can be obtained using the fax-back service:
(206) 635-2222 — request document 859.


Checklist for Input Devices

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Input Components

1. External connection for keyboard

Required Required Required

2. External connection for pointing device

Required Required Required

3. Wireless capabilities

Recommended Recommended Recommended

4. USB game pad or joystick

Recommended Recommended Required


PC 97 Design for Input Devices

Plug and Play and Bus Design for Input Devices

5. Plug and Play device identifier

Required

6. Automatic resource assignment and dynamic disable capabilities

Required

Power Management for Input Devices

7. Compliance with "Device Class Power Management Reference Specification" for input devices

Required

8. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

Device Drivers and Installation for Input Devices

9. Device driver and installation meet Windows and Windows NT standards

Required


Mouse Port and Peripherals

10. General device requirements

Required

11. PS/2 port specifications, if PS/2-style port is used

Required

12. USB Specification and device class specifications, if USB is used

Required

13. IR wireless specifications, if IR device is used

Required

14. RF wireless specifications, if RF wireless device is used

Recommended

15. Remote control provides minimum support, if present

Recommended


Keyboard Ports and Peripherals

16. General device requirements

Required

17. PS/2 specifications by IBM and 8042 chip (or equivalent), if PS/2 used

Required

18. USB Specification and USB device class specification, if USB is used

Required

19. Wireless specifications, if wireless device is used

Required

20. PS/2- style keyboard returns expected scan codes

Required

21. No interference between keyboards for multiple devices

Required

22. Windows and Application Logo keys

Recommended


PC 97 Game Pad Requirements

23. General device requirements

Required

24. USB Human Input Device Class Specification support

Required


Legacy Game Control Port Requirements

25. General device requirements

Required

26. Legacy game port complies with bus and device-class specifications

Required

27. Resource arbitration for non-PCI game port devices

Required

28. Device driver meets Windows 95 driver requirements

Required

29. Device driver for non-USB device supports DirectInput 3.0 APIs

Required

30. MIDI-compatible legacy port uses Sound Blaster pin-out

Required

31. Legacy game port works with Windows-supplied drivers

Required

32. If present, proprietary port meets PC 97 requirements

Required


Chapter 15 Graphics Adapters

This chapter presents the requirements and recommendations for graphics adapters, display monitors, and video playback and capture devices under the Microsoft Windows family of operating systems.

Requirements for MPEG-1 and DVD playback, video input and capture devices, and display monitors are defined in the "Video Components" chapter in Part 4 of guide.


Overview for Graphics Adapters

This section presents the key design issues for graphics adapters under Microsoft Windows. Graphics-related issues for PC 97 are based on the needs of the system to provide fast, high-quality graphics rendering. New games applications that require 3-D graphics or advanced graphics applications such as CAD require improved support in the graphics hardware.

Key PC 97 issues for graphics adapters in general:

  • Design features for a high-performance graphics adapter with hardware acceleration.
  • Optimized hardware support for DirectDraw and Direct3D.
  • Support for TV output for a large TV or VGA monitor.
  • Enhanced Plug and Play capabilities, including multiple-adapter/monitor support.
  • Power management for graphics adapters.

Key issues for Workstation PC 97:

  • Optimized hardware support for high-definition graphics.

Key issues for Entertainment PC 97:

  • Optimized hardware support for high-performance graphics, chiefly for Direct3D applications and MPEG-1 and DVD video playback.

DirectDraw is the Windows system component that allows direct manipulation of video display memory, hardware block transfers (bit-blters), hardware overlays, and page flipping. DirectDraw performs the common functions required by both hardware and software emulation implementations, while maintaining compatibility with the Windows GDI. This provides compatibility with existing applications and device drivers created for Windows. The user will experience the highest quality performance when using new hardware that provides built-in DirectDraw acceleration and rendering capabilities.

Direct3D is a DirectX technology that provides access to hardware acceleration for 3-D rendering. Some basic and general 3-D capabilities will become pervasive in entertainment software by the end of 1997 and should be provided in all graphic cards to improve the performance of 3-D games, business graphics, Internet 3-D file (VRML) viewing, and professional 3-D applications.

Microsoft ActiveMovie provides access to hardware acceleration for MPEG-1 playback, which will become increasingly important to provide high-performance video in the context of games, Internet content viewing, computer-based training, and desktop video conferencing. Some PC 97 hardware requirements ensure support for video playback on all PCs running Windows operating systems.

OpenGL technology is an open industry standard 3-D graphics API used to support 3-D graphics capabilities. This is primarily for high-end or professional 3-D applications such as engineering, modeling, simulation, visualization, animation, 3-D clip art and Internet content (VRML) viewing. OpenGL has some higher requirements for visual rendering precision than general Direct3D devices, but it can also take advantage of appropriate Direct3D hardware. There is also a class of high-end, 3-D graphics hardware specifically targeted at the OpenGL developer which requires an OpenGL client driver rather than or in addition to a Direct3D driver.


System Requirements for Graphics Adapters

This section summarizes the requirements for the graphics adapter for PC 97 system designs.

1. Primary graphics adapter does not use legacy bus

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

For all components in PC 97, buses such as PCI, USB, and IEEE 1394 are strongly recommend over any legacy buses for all devices. For the primary graphics adapter, it is required that the video bus is not ISA. A higher-performance solution is required to optimize performance of the packed-pixel frame buffer. Possible implementations that meet this requirement can include PCI v. 2.1 for all system types or the Intel Accelerated Graphics Port (AGP) interface for x86-based systems.

2. Support for NTSC or PAL TV output, if no large-screen monitor

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

Support for TV output is required if an Entertainment PC 97 system does not include a large-screen entertainment monitor. The ability to connect and use a standard NTSC/PAL television as a large display surface is key to the ability to deliver realistic TV, movie, and game viewing experiences. For mobile PCs, TV output capabilities can be used to enable on-screen presentation graphics in the conference room.

If NTSC is supported, the NTSC system must support 640x480 at 60 Hz. If PAL is supported, the PAL system must support 640x480 and 800x600 at 50 Hz. For details about the related requirements, see "TV Output for PC 97" later in this chapter. This recommendation will not become a requirement for Basic PC systems in the future.

3. Primary graphics adapter works normally with default VGA mode driver

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

The default VGA driver is required for installing the operating system, and the primary adapter must support 4-bit planar VGA mode as described in the Windows 95 DDK. Secondary adapters in multiple monitor configuration do not need to provide VGA compatibility.

4. Support for multiple adapters and multiple monitors

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

This support consists of Plug and Play-related configuration and resource requirements that ensure automatic support for using more than one graphics adapter and support for simultaneous display on two or more monitors. For details, see "Multiple Adapter and Multiple Monitor Support for PC 97" later in this chapter.


Graphics Adapter Basic Features

This section defines requirements for basic features for graphics adapters.

5. General device requirements

Required

These include the standard requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information, see the "Basic PC 97" chapter of this guide.

6. PC 97 minimum resolution

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
800x600x16 bpp | 1024x768x16 bpp | 1024x768x16 bpp
640x480x8 bpp, small LCD |  |

A Basic PC 97 system must contain a graphics adapter that permits a color depth of 16 bpp, minimum. These are the minimum resolution requirements:

  • Basic PC 97: 800x600x16 bpp for Windows desktop and 640x480x16 bpp double buffered for DirectDraw-based full-screen applications.

    The minimum required resolution for a 7"– 10" LCD internal display is 640x480x8 bpp.

  • Workstation PC 97: 1024x768x16 bpp.
  • Entertainment PC 97: 1024x768x16 bpp.

Display RAM requirements are tied directly to the minimum graphics resolution supported by the adapter. The requirement to support double buffering implies 1.5 MB of display RAM. However, PC 97 requirements do not specify minimum display RAM support; rather, the adapter designer can implement any solutions for supporting the minimum resolution requirements.

Note When the user selects 1024x768 resolution, by default the graphics adapter must use a non-interlaced refresh rate.

7. Graphics operations use relocatable registers only

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

VGA registers must not be used to perform graphics operations such as bit-blting, palette setting, and pointer movement. The registers used for these graphics operations can be either I/O locations or memory-mapped locations, but must be relocatable. Normal operation of the system — except system startup and mode setting— should never require using base VGA registers.

8. VESA specifications for ergonomic timing rates: 75 Hz for 1024x768

Required

Recommended: 85 Hz for 1024x768.

The graphics adapter, at a minimum, must support the ergonomic timings documented in the current version of VESA and Industry Standards and Guidelines for Computer Display Monitor Timing for all resolutions up to 1280x1024 that are supported by the monitor. Higher scan rates are preferable under standards published by VESA.

9. Support one or more pixel orderings for color depth

Required

Graphics adapters that support packed-pixel frame buffers at color depths greater than 8 bpp should support one or more of the pixel orderings for color depth that are supported by the Windows DIB engine. (Color ordering is shown from the most-significant bit (MSB) to the least-significant bit (LSB.)

Format | Color ordering
15 bpp | 1 undefined, 5 red, 5 green, 5 blue (URRR RRGG GGGB BBBB)
16 bpp | 5 red, 6 green, 5 blue (RRR RRGGG GGGB BBBB)
24 bpp | 8 red, 8 green, 8 blue (RRRR RRRR GGGG GGGG BBBB BBBB)
32 bpp | 8 undefined, 8 red, 8 green, 8 blue (UUUU UUUU RRRR RRRR GGGG GGGG BBBB BBBB)

10. Downloadable RAMDAC entries to support image color matching

Recommended

For graphics adapters that support 24-bit or higher displays, downloadable RAM digital-to-analog converter (RAMDAC) entries should be included to perform gamma correction in hardware.

Note This will become a requirement in 1998.

11. Graphics adapter supports DDC 2.0 Level 2 monitor detection

Required

This requirement is based on the Display Data Channel DDC 2.0 specification (DDC2B), which defines the communication channel between the display and host system. The adapter must be able to report to the operating system or its driver whether a VGA or an SVGA monitor is attached. The software can use this information to properly manage output to the various displays and to prevent the disabling of TV output if no monitor is attached.

12. Hardware arithmetic stretching

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required (horizontal) | Required (horizontal) | Required (horizontal and vertical)

To support accelerated software playback of motion video, all graphics adapters should support scaling and interpolation to any size window, up to full screen, at any video mode. Doubling (pixel replication) is not an acceptable implementation.

  • For Basic PC 97 and Workstation PC 97, the minimum requirement is horizontal linear or better, up/down arithmetic stretching to any size window.
    Recommended: Bilinear or better horizontal and vertical stretching.
  • For Entertainment PC 97, the minimum requirement is bilinear or better horizontal and vertical, up/down arithmetic stretching to any size window.

Hardware stretching also allows 3-D to be rendered to a smaller back buffer (therefore at higher speeds) and scaled up to the front buffer. Although integral stretches are useful, arbitrary stretches are better because they allow dynamic resizing of the back buffer to maintain constant high frame rates.

Note This capability is recommended but not required for mobile PCs.

13. YUV off-screen surfaces for color space conversion

Required

To support accelerated software playback of video, all graphics cards must support off-screen surfaces in either of the two following packed YUV 4:2:2 sampled formats:

  • YUY2: A byte stream for every pixel in this order: Y1, U, Y2, V
  • UYVY: A byte stream for every pixel in this order: U, Y1, V, Y2

The YUV color space and intensity range is defined by the ITU-R BT.601-4 standard (previously called CCIR-601), where U is CB and V is CR.

These formats use less memory while maintaining high quality, and YUV is the native format for many image and video compression standards.

Note This capability is recommended but not required for mobile PCs.


Multiple Adapter and Multiple Monitor Support for PC 97

This section defines the requirements for ensuring system support for multiple adapters and multiple monitors. This required support ensures that if the user adds a second adapter, resources will automatically be available and that the operating system can automatically manage multiple display adapters.

The actual implementation a user might employ could be one of the following:

  • Multiple adapters added to the PC system
  • A single adapter with a single controller supporting two monitors
  • A single adapter with multiple controllers supporting multiple monitors
  • Any combinations of these scenarios

The support planned for both Windows 95 and Windows NT requires multiple-adapter compatibility in both the graphics adapter and its driver. With this new multiple adapter/multiple monitor support, a single adapter that supports multiple monitors can display independent screen images. This is support beyond the current simultaneous display features for some mobile PCs, which show the same Windows desktop on two displays at the same time.

The operating system support for multiple adapters/multiple monitors requires allowing any secondary graphics adapters to be enabled in VGA mode, thus requiring that VGA for the previous adapter be temporarily disabled.

The support for multiple monitors also assumes that for monitors attached to the same system but showing different images simultaneously, the different displays might have differing X,Y resolution, color depths, and refresh rates plus differing display capabilities.

For technical details about designing for multiple monitor/multiple adapter support, see http://www.microsoft.com/hwdev/devdes/.

14. Plug and Play conflict resolution for multiple monitors/multiple adapters

Required

To ensure Plug and Play for multiple adapter/multiple monitor capabilities, all
non – VGA standard display resources (also known as extended resources, such as register sets and so on) must be capable of being dynamically relocated after system boot.

This is an extension of the earlier requirement, "Graphics operations use relocatable registers only," and is an addition to the basic Plug and Play requirements defined later in this chapter.

15. VGA resources can be disabled by software

Required

A means must be provided to allow a driver to disable its adapter from decoding standard VGA addresses. The purpose of this requirement is to ensure the adapter is independent of all other graphics adapters in the system. The adapter must remain fully functional without the VGA addresses. See also the earlier requirement, "Graphics operations use relocatable registers only."

16. Provide alternate mechanization to Int 10 for initialization

Recommendation

The purpose of this requirement is to avoid problems that occur with multiple ROM mappings at C0000h.

Microsoft is investigating providing an alternate standard for ROM format. Based on such a standard, data tables from the ROM could be used by the driver to program the graphics adapter. A generic mode setting routine could be provided by the operating system to initialize the graphics adapter.


Hardware Acceleration for 2-D Graphics

This section summarizes guidelines related to 2-D DirectDraw graphics features that can be implemented as hardware acceleration features.

Hardware acceleration for 2-D graphics is required for Entertainment PC 97 systems, with individual items in this section marked as required or recommended for that system type.

In general, hardware acceleration for 2-D graphics is not required for Basic PC 97 or Workstation PC 97 systems. The individual items in this section are required or recommended only if a hardware manufacturer chooses to implement hardware acceleration in a graphics adapter. For Workstation PC 97, it is recommended that the PC system manufacturer select graphics adapters that provide hardware acceleration when designing PC systems to support high-quality graphics for use with professional graphics applications.

The following items for DirectDraw acceleration are presented in this section in order of importance.

17. Direct frame buffer access

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

It must be possible for applications to perform direct frame buffer accesses at any time, even while asynchronous accelerator operations are being executed. Without this capability, drivers cannot support DirectDraw or Direct3D on Windows NT, and operations on Windows 95 will not be fully robust.

18. Linear-mapped low resolution modes

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

Decreasing the size of the frame buffer decreases the average polygon size and increases the frame rate for a given scene. Most games currently run in 320x200x8 bpp mode. Providing additional modes provides support for software rendering games and software Direct3D.

If you implement low-resolution support in the hardware, the following are the required low-resolution modes:

320x200x16 bpp
320x200x8 bpp

320x240x16 bpp
320x240x8 bpp

640x400x16 bpp
640x400x8 bpp

The following low-resolution modes are recommended:

400x300x16 bpp
400x300x8 bpp

512x384x16 bpp
512x384x8 bpp

Note In Windows 95, low-resolution capabilities must not be defined in the registry so that they do not appear in the Display Control Panel. In Windows NT, the Control Panel automatically filters out these modes.

19. Transparent blter

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

A transparent blter can perform a blt with a source key transparent color. This assumes that the blter is asynchronous with the host processor.

20. Perform double-buffer swaps with no tearing

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Required

If the frame buffer is large enough to support double-buffering, the hardware should support a mechanism for swapping buffers without visible artifacts such as "tearing." The mechanism for doing this is at the discretion of the hardware designer, but should support tear-free double-buffering for both full-screen and windowed applications.

21. Current scan line of refresh

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

The ability to read the current scan line supports blting or writing to the screen without tearing. Also, in some contexts such as video playback, this support eliminates the need for a back buffer.

22. Programmable blter stride

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

A programmable blter stride ensures that Windows can use linear memory. Using a fixed stride forces Windows to use rectangular memory management, with all the related inefficiencies. It must be possible to specify different strides for the source and the destination on blts.

23. VGA destination color keying for video rectangle

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

The compositing of the video plane under the VGA plane with the VGA pixels must be independently controllable for each VGA pixel. This VGA destination color keying must function in all video modes using either a specific color/color range (on 4-, 8-, 16-, and 24-bit SVGA modes) or an additional alpha blending bits in the color plane bits (on 15- and 32-bit SVGA modes).

This color keying of the VGA will allow certain VGA pixels to be replaced by the underlying video pixels on a pixel-by-pixel basis. This feature enables VGA video overlays, controls, Windows popups, dialogs, and so on. It must also work at the same time as any vertical/horizontal scaling that is active for the underlying video.


Hardware Acceleration for 3-D Graphics

This section summarizes guidelines related to Microsoft Direct3D technologies that can be implemented as hardware acceleration features. Supporting the items in this section can result in improved performance and better memory use.

Hardware acceleration for 3-D graphics is required for Entertainment PC 97 systems, with individual items in this section marked as required or recommended for that system type.

In general, hardware acceleration for 3-D graphics is not required for Basic PC 97 or Workstation PC 97 systems. The individual items in this section are required or recommended only if a hardware manufacturer chooses to implement hardware acceleration in a graphics adapter. It is recommended that the PC system manufacturer select graphics adapters that provide 3-D hardware acceleration when designing PC systems to support high-quality graphics for use with professional graphics applications or for "multimedia" systems.

Note For specific features for Workstation PC 97, this section assumes a workstation system designed to support a graphics-intensive use such as CAD. These requirements are not general requirements for Workstation PC 97.

There are two broad classes of hardware suitable for OpenGL-based 3-D applications. At the low end, OpenGL can drive Direct3D devices, so any Direct3D device is in principle compatible with OpenGL. However, OpenGL has conformance requirements for rasterization, including specific requirements for subpixel precision and Z-buffer calculations, which are more precise than the Direct3D software rendering library.

Direct3D hardware designed to support OpenGL-based applications must be capable of meeting the OpenGL rasterization rules, and Direct3D drivers must report through the appropriate caps bit, whether or not the hardware actually conforms to OpenGL requirements.

There is also a class of graphics adapters designed specifically for OpenGL. Although these cards can also expose their 3-D capabilities through a Direct3D driver, they generally expose their capabilities to OpenGL through a client driver.

Information about OpenGL rasterization requirements and conformance rules is available from the OpenGL Architectural Review Board. Additional information is available on the Usenet newsgroup for OpenGL: comp.graphics.opengl.

Hardware that implements 32-bpp display modes (for example, display hardware for high-end engineering workstations) should implement RGB mode rasterization. OpenGL supports a color index mode, but most OpenGL applications require RGB mode rasterization.

24. Basic RGB rasterization, if RGB mode is supported in hardware

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Required

In RGB mode under Direct3D, shading across a surface is accomplished by independently interpolating in all color components. If 3-D hardware supports RGB mode rasterization, it must support the following features:

  • RGB rasterization. This must use the red, green, and blue color interpolates.
  • Flat and Gouraud shading. For flat shading, a single color is applied to a surface region based on the color of a specific point on a polygon. For Gouraud shading, more realistic color is provided by gradually filling the region using interpolated colors based on the colors of each individual vertex and the distance from the vertex.
  • Point-sampled, perspective-correct texturing. For this method of texture mapping, the distance is computed between a pixel to be displayed and the pixels at surface vertices, plus perspective computation is carried out to ensure that the texture map includes perspective distortions that match those on the 3-D surface.

25. Recommended RGB rasterization features

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

If 3-D hardware supports RGB mode rasterization, the following additional features in hardware are also recommended:

  • Fog coloring and depth-cueing operations. These are provided for depth of field visual cueing. Fog coloring provides special depth shading to a 3-D object, with a surface color mixed in proportion to the fog value.
  • Modulated alpha coloring. With this method, the shading color and texture map are mixed together directly, with the alpha for the pixel color taken from the texture map.
  • Bilinear filtered textures. This method ensure smooth transition of an object across a texture map by selecting color for texture map pixels based on computations that use a weighted average to mix colors for a particular texture map pixel based on color values for the nearest pixels in the texture map.
  • Generalized trilinear MIP-mapped textures. MIP mapping uses multiple texture maps of differing resolutions and sizes to represent a texture. For trilinear averaging, the resolution is computed for the texture map, and then a weighted average is computed of nearby texture maps in all three dimensions. With this method, the texture scales smoothly as the surface increases in size.

26. Destination alpha blending for transparency effects

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

For destination alpha blending, transparent primitives are blended with the background behind them, updating not only the frame buffer but also a cumulative transparency for the background that can affect the rendering of subsequent primitives. This method is capable of the greatest visual accuracy but is computationally expensive, requires the hardware to support a dedicated alpha buffer, and is recommended only for high-end workstations that must support complex 3-D image compositing and volume-rendering applications.

27. Source alpha blending for transparency effects

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

For source alpha blending, transparent primitives are blended with the background, but the background transparency is not updated. This method provides good visual accuracy if there are not too many overlapping transparent objects.

28. Stippled alpha blending (screen door transparency)

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Optional | Optional | Optional

Instead of either a source alpha blend or a full destination alpha blend, Direct3D can be switched to a mode where it uses stipple patterns keyed off the interpolated alpha value. This saves destination reads and multiplies, and does not require sorting of primitives. This mode is simple to implement, but is not visually acceptable for engineering and other professional 3-D uses.

29. Double buffer support for workstation-quality 3-D graphics

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Recommended

If hardware designed for the workstation market supports 3-D acceleration, it must also provide two 16-bpp or 24-bpp frame buffers.

Workstation applications and many games and consumer titles require smooth animation. In many cases, this requires the display hardware to support two pixel buffers, although some applications and hardware designed for the entertainment market can provide smooth animation using other techniques.

30. Hidden surface removal

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Recommended

Typically, 3-D applications perform hidden surface elimination through the use of Z-buffers, although many game applications use specialized geometry and algorithms instead. If hardware targeting the workstation market supports 3-D acceleration, it must also provide at least a 16-bit Z-buffer.

31. Palettized textures

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

Support for palettized textures allows for much less texture memory. Particularly useful are 4-bit and 8-bit palettized textures, each with their own palettes.

32. Support for improved parallelism between host and rasterizer

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required | Required

Hardware that provides 3-D acceleration should take advantage of techniques available to improve parallelism between the host controller and the rasterizer, which can include use of DMA support, FIFOs, or other methods. The choice of technique is up to the manufacturer, but it should provide for good buffering of performance differences between host and rasterizer in cases where there is a mix of large and small triangles.

33. Triangle setup

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

For much 3-D hardware, passing a mass of data over the bus for each triangle creates a bottleneck. Advanced hardware can take a higher-level and more compact description of the triangle and compute this setup data on the fly. The setup is faster, and the bus transfer is also simpler. Adding triangle setup capabilities for workstation and entertainment systems is strongly recommended.

Any 3-D hardware intended to support professional 3-D markets that implements triangle setup must include subpixel correction.


TV Output for PC 97

This section summarizes the key design issues and requirements for TV output capabilities, which are recommended for all system types and required for any Entertainment PC 97 PC system that does not include a large-screen entertainment monitor.

The requirements in this section apply only if the capability is present on a PC system or on a graphics adapter that supports TV output capabilities. Some TV output capabilities listed in this section are required only for Entertainment PC 97.

The required support allows an NTSC/PAL TV to be used as a primary or secondary display surface for the Windows operating system and Windows-based applications. Such a display surface allows more realistic game, video, and multimedia experiences for users who want to use the large-screen TV they might already own.

If TV output capabilities are provided in a PC system, support is required for either NTSC or PAL TV output standards:

  • NTSC (National Television System Committee) refers to the TV standards originally formulated in the United States. Countries using NTSC standards include Canada, Japan, and Mexico.
  • PAL (Phase-Alternation Line) refers to a TV system first developed in Germany. Countries using PAL standards include Austria, Belgium Brazil, Denmark, Finland, the Netherlands, Norway, Sweden, Switzerland, and the U.K.

For information about world TV standards, see:

http://www.bbc.co.uk/aberdeen/eng_info/world_tv.htm

34. Support both NTSC and PAL output

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

Either NTSC or PAL standards must be supported if TV output capabilities are included in the adapter or system design; however, it is recommended to support both standards. If NTSC is supported, the NTSC system must support 640x400 and 640x480 at 60 Hz. If PAL is supported, the PAL system must support 640x480 and 800x600 at 50 Hz. Whether either or both output standards are supported, software must have the capability to enable and disable TV and VGA output independently.

Note For NTSC, 60-Hz mode described in this section is actually 59.940 Hz.

35. Default boot mode supports appropriate locale

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

TV output must work automatically as the primary display if a VGA monitor is not attached. The graphics adapter must default to modes compatible with TV output. Adapters manufactured for NTSC countries should default to 60-Hz modes; those manufactured for PAL countries should default to 50-Hz modes.

36. Underscan scaling

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

The TV-output adapter must be able to correct horizontal and vertical overscan using hardware scaling. This allows 640x480 resolution modes to fit onto NTSC displays and 800x600 modes to fit onto PAL displays. Driver software must have the capability to enable and disable scaling and also adjust scaling for compatibility with a variety of TVs. When TVs age, overscan reduces, so less scaling is required. Also, overscan can be enabled by software when the PC is playing full-screen video.

37. Flicker filter

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

The TV-output adapter must use multi-line (three-tap minimum) hardware filtering techniques for flicker reduction. Enable, disable, and adjust capabilities for the flicker filter must be able to be controlled by software. Also, overscan can be enabled by software when the PC is playing full-screen video.

Note Flicker filter is not required in overscan mode.

38. Proper termination

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Proper termination is required so that optimal picture quality from any connector does not require displays to be attached to other connectors. For example, a VGA monitor must not be required for the S-Video output to appear properly.

39. Support RCA-style composite video and S-Video connectors

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

S-Video dramatically improves the picture quality of the NTSC/PAL scan converter, compared to composite video. This standard is designed to reduce crosstalk between chrominance and luminance signals and to increase the luminance bandwidth capability of the TV. For a description of this standard, see:

http://www.bbc.co.uk/aberdeen/eng_info/s-video.htm

Notice that most European TV sets now have two SCART sockets (also called Peritel); one allows stereo audio and composite video input/output switchable to RGB inputs; the other supports switching from composite input to S-Video input. The first can be used to connect a satellite receiver for RGB capability; the second can be used to connect a VCR using S-Video for TV output. A camcorder usually has connections for composite video, stereo audio, and S-Video. For a description of the SCART standard, see:

http://www.bbc.co.uk/aberdeen/eng_info/scart.htm

40. Support both VGA and TV output

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

In addition to TV output, the system must also support VGA output to ensure that users with existing larger-screen VGA monitors can use this output capability.

Note Simultaneous output to VGA monitor and TV is recommended, but not required.

41. Positioning

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

Software must be able to program the TV-output hardware to position the TV image in increments of four pixels horizontally and four scan lines vertically.

42. Software detection of TV connection

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

Software must be able to read the TV output hardware to detect whether a TV is attached to either S-Video or composite output connectors. (Detection of a VGA monitor is achieved using the separate DDC requirement for graphics adapters and monitors.) This is required to allow the operating system and graphics drivers to support display output correctly during the startup sequence (for example, determining what resolution and refresh rate to use), and for applications to adjust their user interfaces appropriately to the screen capabilities.


PC 97 Design for Graphics Adapters

This section summarizes requirements related to the design initiatives for PC 97 defined in Part 1 of this guide.


Plug and Play and Bus Design for Graphics Adapters

The items in this section summarize requirements for Plug and Play and other resource- and bus-related capabilities. The specifications in this section are required for all PC 97 systems.

Note See also the requirement "Graphics operations must use relocatable registers only" earlier in the "Graphics Adapter Basic Features" section.

43. Plug and Play device identifier

Required

The device must have a unique device ID using the format required for its bus. A PCI device must comply with PCI 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide.

44. Conflict resolution, VGA compatibility, and extended register

Required

Changing or adding a graphics adapter to the system must not require changing jumpers or switches on either the card or the system board. The system must have a method for automatically relocating the resources used by a graphics adapter on the system board in the case that a graphics adapter expansion card is added to the system. In the event of irreconcilable conflict with other devices on the system, the system must be able to disable one of the adapter in order to prevent the system from stalling.

The system must support the VGA graphics standard for application compatibility and for the Windows clean-boot error-recovery process. If a VGA BIOS exists on the graphics adapter, it must be able to configure its base address to C0000h and one (minimum) alternate address to prevent conflicts.

Extended resources are additional I/O ports, direct-access frame buffers, or data transfer areas on a graphics adapter that use more resources than does standard VGA. The Windows configuration manager must be able to map the resources to avoid conflicts with other system devices. At least one alternate configuration must be provided for each non – VGA display resource in the event of conflict during initial program load (IPL) boot.

The software drivers and VGA BIOS (if used) must be able to use alternate configuration register addresses. The system must be able to disable or relocate VGA resources from C0000h dynamically.

For additional related requirements for multiple monitor support, see the section "Multiple Adapter and Multiple Monitor Support for PC 97" earlier in this chapter.

45. PCI base address registers populated correctly for PCI graphics device

Required

The display driver for Windows 95 queries the actual device to find its register locations and so on. The PCI Base Address Registers must be populated correctly for this information to be correct in the registry.

The use of an IRQ for a video device is not recommended unless it is being physically used by the adapter — the Interrupt Pin Register (3Dh) should be zero (0). Do not request the IRQ for compatibility with the original VGA standard; request the IRQ only if it will be used on the adapter. If you want to allow this IRQ, a jumper or soft-setting utility could be used. If the BIOS configures an IRQ for the device, then Windows 95 will report this IRQ in the registry. Alternatively, the IRQ could be requested by using the INF for the device.

46. Linear packed pixel frame buffer, relocatable above 16 MB

Required

Note For DirectDraw, the graphic adapter's chip set must support linear access to the frame buffer by the host.

Windows 95 is optimized for a graphics adapter with a packed-pixel frame buffer at all supported resolutions. Memory-mapped packed-pixel frame buffers also provide a fast and simple interface between Windows 95 and the graphics adapter. The Windows 95 DIB engine provides a very fast display by writing directly to packed-pixel frame buffers, and this architecture requires that the hardware developer write only a small, simple device driver.

For optimized support with Windows 95, a linear packed-pixel frame buffer is required over a bank-switched frame buffer. Use 32-bit addresses to allow the linear frame buffer to be placed above the 16-MB ISA boundary, which enables a system to be populated with large amounts of RAM.

If memory or other resources conflict with the frame buffer being mapped into a linear address space, the page frame address can be used with minimal degradation of performance.

47. Option ROM supports Display Data Channel DDC 2.0, Level B

Required

This requirement applies for x86-based systems. The option ROM for the graphics adapter must meet current DDC host requirements documented in the Display Data Channel DDC 2.0 specification published by VESA. This standard defines the functions that support the data channel between the graphics adapter and a DDC-compliant monitor.

48. Do not use IRQ 2(9)

Required

Some VGA-compatible adapters support ISA IRQ 2 (PIC interrupt 9) as the hardware interrupt for vertical refresh. This interrupt, which can be used to synchronize updates to VGA registers during vertical refresh, exists mainly for compatibility with EGA-style adapters and is used by few modern graphics adapters. Windows 95 does not use it. Therefore, if IRQ 2(9) capability is included on your graphics adapter (unless you use it during the card initialization), it should power up inactive when power is turned on and should not actively drive the bus.

The adapter must also not claim IRQ 2(9) when enumerating device resources. The Windows resource arbitrator assigns devices to all other IRQs before using IRQ 2(9), so it will most likely remain unused. In this context, IRQ 2(9) refers to the IRQ signal logically mapped to IRQ 2 on the ISA bus (for historical reasons). From a hardware designer's point of view, however, IRQ 9 refers to pin 19 of the slave 8259 PIC.


Power Management for Graphics Adapters

This section summarizes the specific power management requirements for graphics adapters.

49. Compliance with "Device Class Power Management Reference Specification"

Required

The "Device Class Power Management Reference Specification" for the display device class provides definitions of the OnNow device power states (D0 – D3) for display and graphics devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class, if any. Power states D0 and D3 are required. Other power states are recommended.

50. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for display devices is an optional feature.

51. Adapter complies with VBE/Core 2.0 extensions for power management

Required

The VESA BIOS Extension Standard / Core Functions 2.0 specification defines extensions to VGA ROM BIOS services for power management.


Device Driver and Installation for Graphics Adapters

This section summarizes the requirements for graphics adapters. The specifications in this section are required for all PC 97 systems.

For additional related requirements for multiple monitor support, see the section "Multiple Adapter and Multiple Monitor Support for PC 97" earlier in this chapter.

52. Device driver and installation meet Windows and Windows NT standards

Required

The standard requirements for drivers and installation include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry. The driver must not use INI files for configuration settings.
  • The correct .DRV file or any other files specified in the device's INF must be installed in the correct locations. For manufacturer-provided files, the vendor must not be identified as Microsoft, and all other copyright and version information must be correct for the manufacturer.
  • Driver installation and removal use Windows-based methods. Drivers must
    be installed using Windows methodology only; however, any software applications included with the device can be installed using an alternate Windows-based installation method.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode components are provided in order to operate under Windows, except for any Windows 95 .DRV file.

    For Windows 95, the display driver (.DRV) component that is loaded and called by the Windows GDI is a Win16 module.

  • Manufacturer-provided control panel applications do not disable default Windows functionality, including refresh rate setting.
  • Driver does not bypass any Microsoft-provided system components, including Gdi.exe, Kernel.exe, User.exe, Dibeng,dll, Mmsystem.dll, Ddraw.dll, D3d*.dll, and so on.

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.

53. Applications provided with device meet Windows standards

Required

Any Windows-based applications provided with the device must meet Microsoft requirements for software compatibility as indicated by the "Designed for Microsoft Windows" logo.

54. Driver support for virtual desktop

Recommended

For Windows 95, this recommendation means that the driver uses the named function export called ValidateDesk and correctly stores desktop size and screen size in the Registry. For information, see the Windows 95 DDK.

For Windows NT 4.0, applications should use the panning fields in the DEVMODE structure to set the virtual desktop size.

55. Driver support for dynamic color bit-depth change

Required

The graphics adapter must operate properly and not fail when asked by the operating system to change the color depth.


References for Graphics Adapters

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Design guidelines for DirectX, multiple monitor/multiple adapter support, and other technologies.

http://www.microsoft.com/hwdev/devdes/

Windows 95 DDK, Windows NT DDK, and DirectX DDK

MSDN Professional membership

Display Data Channel DDC 2.0 (includes VBE/DDC)
VESA BIOS Extension Standard / Core Functions 2.0
VESA and Industry Standards and Guidelines for Computer Display
Monitor Timing

Video Electronics Standards Association
2150 North First Street, Suite 440
San Jose, CA 95131-2029
Telephone: (408) 435-0333
Fax: (408) 435-8225
http://www.vesa.org

World TV and S-Video interface standards

http://www.bbc.co.uk/aberdeen/eng_info

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm


Checklist for Graphics Adapters

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Graphics Adapters

1. Primary graphics adapter does not use legacy bus

Required Required Required

2. Support for NTSC or PAL TV output, if no large-screen monitor

Recommended Recommended Required

3. Primary graphics adapter works normally with default VGA mode driver

Required Required Required

4. Support for multiple adapters and multiple monitors

Required Required Required


Graphics Adapter Basic Features

5. General device requirements

Required

6. PC 97 minimum resolution

800x600x16 bpp | 1024x768x16 bpp | 1024x768x16 bpp
640x480x8 bpp, small LCD |  |

7. Graphics operations use relocatable registers only

Required Required Required

8. VESA specifications for ergonomic timing rates: 75 Hz for 1024x768

Required

9. Support one or more pixel orderings for color depth

Required

10. Downloadable RAMDAC entries to support image color matching

Recommended

11. Graphics adapter supports DDC 2.0 Level 2 monitor detection

Required

12. Hardware arithmetic stretching

Required (horizontal) Required (horizontal) Required (horizontal and vertical)

13. YUV off-screen surfaces for color space conversion

Required

Multiple Adapter and Multiple Monitor Support for PC 97

14. Plug and Play conflict resolution for multiple monitors/multiple adapters

Required

15. VGA resources can be disabled by software

Required

16. Provide alternate mechanization to Int 10 for initialization

Recommendation

Hardware Acceleration for 2-D Graphics

17. Direct frame buffer access

Required Required Required

18. Linear-mapped low resolution modes

Recommended Recommended Required

19. Transparent blter

Recommended Recommended Required

20. Perform double-buffer swaps with no tearing

Recommended Required Required

21. Current scan line of refresh

Recommended Recommended Required

22. Programmable blter stride

Recommended Recommended Recommended

23. VGA destination color keying for video rectangle

Recommended Recommended Required

Hardware Acceleration for 3-D Graphics

24. Basic RGB rasterization, if RGB mode is supported in hardware

Recommended Required Required

25. Recommended RGB rasterization features

Recommended Recommended Recommended

26. Destination alpha blending for transparency effects

Recommended Recommended Recommended

27. Source alpha blending for transparency effects

Recommended Recommended Recommended

28. Stippled alpha blending (screen door transparency)

Optional Optional Optional

29. Double buffer support for workstation-quality 3-D graphics

Recommended Required Recommended

30. Hidden surface removal

Recommended Required Recommended

31. Palettized textures

Recommended Recommended Recommended

32. Support for improved parallelism between host and rasterizer

Recommended Required Required

33. Triangle setup

Recommended Recommended Recommended

TV Output for PC 97

34. Support both NTSC and PAL output

Recommended Recommended Recommended

35. Default boot mode supports appropriate locale

Recommended Recommended Required

36. Underscan scaling

Recommended Recommended Required

37. Flicker filter

Required Required Required

38. Proper termination

Required Required Required

39. Support RCA-style composite video and S-Video connectors

Recommended Recommended Required

40. Support both VGA and TV output

Required Required Required

41. Positioning

Recommended Recommended Required

42. Software detection of TV connection

Recommended Recommended Required


PC 97 Design for Graphics Adapters

Plug and Play and Bus Design for Graphics Adapters

43. Plug and Play device identifier

Required

44. Conflict resolution, VGA compatibility, and extended register

Required

45. PCI base address registers populated correctly for PCI graphics device

Required

46. Linear packed pixel frame buffer, relocatable above 16 MB

Required

47. Option ROM supports Display Data Channel DDC 2.0, Level B

Required

48. Do not use IRQ 2(9)

Required

Power Management for Graphics Adapters

49. Compliance with "Device Class Power Management Reference Specification"

Required

50. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

51. Adapter complies with VBE/Core 2.0 extensions for power management

Required

Device Driver and Installation for Graphics Adapters

52. Device driver and installation meet Windows and Windows NT standards

Required

53. Applications provided with device meet Windows standards

Required

54. Driver support for virtual desktop

Recommended

55. Driver support for dynamic color bit-depth change

Required


Chapter 16 Video Components

This chapter presents the requirements and recommendations for display monitors, DVD playback, and video input and capture devices under the Microsoft Windows family of operating systems.

Requirements for graphics adapters and TV output capabilities are defined in the "Graphics Adapters" chapter in Part 4 of this guide. For requirements related to digital cameras and other digital image input devices, see the "Scanners and Digital Cameras" chapter in Part 4 of this guide.


Overview for Video Components

This section presents the key design issues for video components under Microsoft Windows. New applications that require MPEG and other video playback for games or advanced graphics applications require high-performance support in the video hardware.

Key design issues for basic video requirements:

  • Power management for video devices. Under the OnNow design initiative, specifications are being developed for standard interpretation of the four standard device power states (D0 – D4) plus a set of minimum power capabilities for devices in this class. These specifications will cover power consumption, command latency, device functionality, and Wakeup event definitions.
  • Connection with consumer-electronics video devices, such as TV, VCR, camcorder, and so on.
  • High-quality playback of multiple audio/video source streams:
    • DVD-ROM and CD-ROM movies, games, and applications
    • Digital broadcast satellite input
    • Internet, using ISDN, cable modem, ATM, DVB, and so on
    • Video conferencing

Key design issues for Entertainment PC 97:

  • For TV and movie watching, the system must provide full image quality, smooth playback, stereo or surround audio, and synchronized audio and video.

    This also means support for large-screen VGA monitors that offer higher resolution and better image quality than televisions offer. Large-screen VGA monitors will ensure a high-quality user experience for family-oriented and multiplayer computer entertainment applications.

  • Non-exclusive operation — that is, other tasks running in the system don't interrupt video. This is necessary for the PC to carry on background management tasks, such as downloading e-mail or handling an incoming telephone call, without impacting TV or movie playback.

    For PCs at Entertainment PC 97 price level, customers expect that software should be capable of multitasking while providing more functionality and dramatically better content. Windows-based PCs can't deliver this if the CPU and PCI bus are overused. Therefore, the end-to-end video subsystem, from input source to rendering, must be capable of sustaining full quality playback and display for complex applications.


System Requirements for Video Components

This section summarizes the requirements for video components for PC 97 system designs.

1. DDC 2.0 Level B-compliant color display with unique EDID identifier

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

A monitor designed for or included with a PC 97 system must be compliant with Display Data Channel Standard version 2.0, Level B (DDC2B), which defines the communication channel between the display and host system. Also, the monitor must transmit an Extended Display Identification Data (EDID) structure containing unique ID Manufacturer Name and ID Product Code identifiers, plus all required fields defined in Section 3 of Extended Display Identification Data Standard 2.0 (or higher).

2. System supports MPEG-1 playback

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

Windows provides operating-system playback support for MPEG-1 through Microsoft ActiveMovie. To support this capability, system manufacturers are required to implement arithmetic stretching and color space conversion in their PC 97 graphics subsystems as defined in the "Graphics Adapters" chapter in Part 4 of this guide. For more information about performance and hardware requirements, see "MPEG-1 Playback Requirements" later in this chapter.

If the device supports MPEG-2 acceleration, the requirements are defined in this chapter as part of the requirements for PC 97 DVD playback.

3. PC 97 DVD playback requirements, if PC system includes DVD-Video

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required with DVD-Video | Required with DVD-Video | Required

All PC 97 systems that include DVD-Video support must also provide PC 97 playback support for DVD content, as defined in "DVD Playback Requirements" in this chapter.

4. Video input and capture

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

If implemented in a PC 97 system, video input and capture devices must meet the requirements defined in "Video Capture Requirements" in this chapter. All video input and capture devices must have WDM Imaging minidrivers that have passed WHQL testing.


Video Components Basic Requirements

This section summarizes both the basic hardware design features for video components and the specific features for PC 97.

5. General device requirements

Required

These include the standard requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information see the "Basic PC 97" chapter of this guide.

Note To ensure proper connection by the user between VGA monitor, S-Video, and composite cables and connectors, an icon must be added to any external connector, using vendor designs or any appropriate designs provided in Appendix A, "Icons."


PC 97 Design for Video Components

This section summarizes requirements related to the design initiatives for PC 97 defined in Part 1 of this guide.


Plug and Play and Bus Design for Video Components

The items in this section summarize requirements for Plug and Play and other resource- and bus-related capabilities.

6. Plug and Play device identifier

Required

Each device must have a Plug and Play device identifier as required for the bus it uses, as defined in Part 3 of this guide. For example, a PCI device must comply with PCI v. 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide.

7. Conflict resolution and dynamic disable capabilities

Required

The operating system must be capable of automatically assigning, disabling, and relocating the resources used by this device when necessary, using the method required for the related bus class. All configuration settings must be capable of being made through software, with no system reboot required. Changing or adding this device to the PC system must not require changing jumpers or switches on either the adapter or the system board to set resource assignments. In the event of an irreconcilable conflict with other devices on the system, the operating system must be able to disable the device to prevent the system from stalling. The device must not claim any resources while disabled.

8. Dependent MPEG device is not enumerated independently

Required

If an MPEG device is implemented as a dependent device on a multifunction adapter, it must not be enumerated independently. Instead, its parent must be responsible for installing and loading its MPEG driver and updating the registry on its behalf.


Power Management for Display Devices

This section summarizes the specific power management requirements for graphics and display devices.

9. Compliance with Device Class Power Management Reference Specification

Required

The "Device Class Power Management Reference Specification" for the display device class provides definitions of the OnNow device power states (D0 – D3) for graphics adapters and monitors. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class, if any.

10. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for the display device class devices is an optional feature.


Device Driver and Installation for Video Components

This section summarizes the requirements for video components.

11. Device driver and installation meet Windows and Windows NT standards

Required

The manufacturer does not need to supply a driver if a standard driver provided with the operating system can be used. If the manufacturer supplies drivers, the requirements for installation include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry. The driver must not use INI files for configuration settings.
  • The correct minidriver, VxD, or any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations. For manufacturer-supplied files, the vendor must not be identified as Microsoft, and all other copyright and version information must be correct for the manufacturer.
  • Driver installation and removal uses the Windows-based methods defined in the Windows 95 and Windows NT DDKs. However, any software applications included with the device can be installed using an alternate Windows-based installation method.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).
  • If support using WDM drivers is provided in the operating system, the driver supplied by the manufacturer must be a WDM minidriver.

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.

Note Monitor support for Windows is installed using a Monitor INF file, as defined in the Windows 95 and Windows NT DDKs.

12. Applications provided with device meet Windows standards

Required

Any Windows-based applications provided with the device must meet Microsoft requirements for software compatibility as indicated by the "Designed for Microsoft Windows" logo. Applications installed with the device must use a standard Windows-based installation method, as defined in the Win32 SDK.


MPEG-1 Playback Requirements

This section summarizes the minimum requirements for all desktop systems to support MPEG-1 playback.

13. Audio and video decode performance: 30 fps, minimum

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

MPEG-1 audio and video decode performance with ActiveMovie must be greater than or equal to 30 frames per second (fps) as measured by the Average Frame Rate Achieved property of the ActiveMovie Video Renderer.

14. Graphics support for color space conversion and arithmetic stretching

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required | Required | Required

To support accelerated software playback of motion video, the graphics subsystem must support the following capabilities:

  • Hardware arithmetic stretching.

    For Basic PC 97 and Workstation PC 97, the minimum requirement is linear or better horizontal, up/down arithmetic stretching to any size window.

    For Entertainment PC 97, the minimum requirement is linear or better horizontal and bilinear or better vertical, up/down arithmetic stretching to any size window.

  • YUV off-screen surfaces for color space conversion.

For more information about these requirements and other hardware acceleration requirements for the graphics subsystem, see the "Graphics Adapters" chapter in Part 4 of this guide.

Note These capabilities are not required for mobile PCs.


DVD Playback Requirements

The items in this section are requirements related to video and audio playback capabilities for a PC system that includes a DVD-ROM device and software support for DVD-Video playback. For more information about DVD requirements, see the "Storage and Related Peripherals" chapter in Part 4 of this guide.

15. PC 97 DVD playback requirements

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required with DVD | Required with DVD | Required

All PC 97 systems that include DVD-ROM drives and support for DVD-Video playback using software or hardware audio/video decodes must provide DVD data format audio/video decoding and rendering using the Microsoft ActiveMovie multimedia architecture, according to the following guidelines:

  • Video requirements. The system must decode MPEG-2 Main Profile, Main Level video streams, including the following:
    • ISO/IEC 13818-2 (video) specification at Main Profile and Main Level.
    • 10 megabit/second sustained input as the peak rate for DVD-Video content for Basic PC 97 and Workstation PC 97.

    For Entertainment PC 97, the full 15 megabit/second rate specified by the MPEG-2 industry standard is required for forward compatibility with future MPEG-2 streams, such as digital satellite broadcast.

    • 720x576x30 (H/V/F) maximum sampling density.
    • Test procedures defined by ISO/IEC 13818-4.
  • Audio requirements. DVD MPEG-2 and Dolby AC-3 audio must be decoded and digitally downmixed to Dolby ProLogic-encoded stereo (2 channels, minimum). Either the original multi-channel streams or the downmixed stereo surround 2-channel streams must be available to software in PCM format. Output can use a digital connection (USB or IEEE 1394) or an analog audio connection.

    DVD audio must be mixed with other PC audio streams. Microsoft recommends digital mixing.

    The system must support MPEG-2 audio decode and output as follows:

    • ISO/IEC 13818-3 (audio) specification at Layer II.
    • 1130 kilobit/second sustained input.
    • Test procedures defined by ISO/IEC 13818-4.
  • Synchronized audio and video. Audio and video decoders and rendering mechanisms must be in synch, but this requirement does not define whether the solution is implemented in software or hardware. A general broadcast industry guideline is that audio must not be out of synch with video by more than 45 milliseconds late (that is, 1.5 frames at 30 fps) and no more than 20 milliseconds early (0.66 of a frame at 30 fps).
  • Independent audio/video streams supported by decoder subsystem. This is necessary for support of interactive DVD titles, plus MPEG-2 and AC-3 content from CD-ROM, the Internet, and so on.
  • WDM for MPEG-2 acceleration. For both Windows 95 and Windows NT, MPEG-2 decode hardware acceleration must be supported using a Win32 Driver Model (WDM) audio/video decoder minidriver.

16. No dropped or duplicated frames

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

No MPEG-2 video frames can be dropped or duplicated during full-screen playback. This implies that the video frame rate and VGA refresh rate are locked. This requirement guarantees a user experience equivalent to lower cost, dedicated consumer-electronics devices such as DVD players and VCRs.

It is generally accepted in the video broadcast industry that any level of frame slippage will be noticeable to viewers and will be considered an annoyance compared to the smooth viewing experience provided by standard broadcast television, VCRs, and so on.

17. Background tasks do not interfere with DVD playback

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

Normal background tasks that occur during foreground, full-screen DVD playback should not interfere with the audio or video playback. This applies to background tasks initiated by applications included with the PC, such as home control, and so on.

This is a critical requirement for Entertainment PC 97 designs, whose users will rely on the PC to perform normal day-to-day operations simultaneously with non-interactive (linear) movie playback. Some specific examples of operations that must not interfere with DVD playback are the following:

Answering the telephone to receive voicemail or fax. This applies only to telephony software included with the PC, not third-party software installed by the user. Notice that telephone answering must not be automatically disabled during DVD playback unless explicitly configured by the user.

Running scheduled communications tasks such as automatic connection using the modem, ISDN, or LAN to transfer e-mail and faxes, download cached Internet content, and so on.

Note Programs that make intensive use of system resources or that are designed for interactive foreground operation are excluded from this requirement. This includes games, video and audio playback, speakerphone, and disk utilities, such as error checking, defragmentation, and virus protection.

18. Subpicture compositing, if DVD drive supports video discs

Required

Because of possible legal requirements to support closed captioning, DVD-
Video – enabled PCs must fully support "subpictures" as defined in the DVD specification. This includes the ability to overlay an animated bitmap with the correct pixel aspect ratio onto the decoded active video with alpha blending. This might be implemented with a display adapter that has two overlay surfaces (one of which must be alpha blended), or it might be implemented by compositing in the MPEG decoder subsystem.

19. All general device requirements for video components

Required

These are defined in the "Video Components Basic Requirements" and "PC 97 Design for Video Components" sections earlier in this chapter.


Video Capture Requirements

This section summarizes both the basic hardware design features for video capture and the specific features for PC 97. Video capture and playback are not required for PC 97. However, if this feature is implemented, the requirements in this section must be met.

For requirements related to digital cameras and other digital image input devices, see the "Scanners and Digital Cameras" chapter in Part 4 of this guide.

20. Wave audio capture

Recommended

If the video capture device supports wave audio capture, it must support the waveform audio command set defined in the Win32 SDK.

21. Synchronized audio and video capture clocks

Recommended

Genlock capabilities are recommended to prevent problems that occur when there is no clock communication between video and audio cards. Notice that in professional video, the audio clock is usually derived from the video clock.

22. Time code reading

Recommended

Time code is a standard representation of time developed for the video and film industries. Time code is an absolute time format expressed in hours, minutes, seconds, and frames as required by frame-accurate video editing applications.

  • For NTSC-based systems, the defining standard for time code is ANSI/SMPTE 12M. Both drop and non-drop frame formats should be supported.
  • For PAL-based systems, the defining standard is IEC 461. For film, the defining standard is SMPTE Recommended Practice RP 136.

23. WDM imaging minidriver

Required

Each video input or capture device must have a WDM imaging minidriver that has passed WHQL testing.

24. All general device requirements for video components

Required

These are defined in the "Video Components Basic Requirements" and "PC 97 Design for Video Components" sections earlier in this chapter.


Desktop Monitor Requirements

This section lists the hardware requirements and PC 97 features for desktop monitors.

25. Minimum graphics resolution, based on monitor size

Required

With the following higher resolutions, a larger desktop area can be displayed, more applications can be shown on the display at once, individual windows can
be larger, applications can be fully displayed side by side, and so on.

  • 7" – 10" LCD internal monitor = 640x480
  • 14" – 15" external monitor or 11" – 12" LCD = 800x600
  • 17" monitor = 1024x768, non-interlaced
  • 19" – 21" monitor = 1280x1024, non-interlaced

Note These specific monitor sizes are not listed as recommended or required, but included merely to show the resolution rates expected from various monitor sizes.

26. ICC color matching support

Required; recommended for LCD

The Image Color Matching (ICC) APIs and functionality for Windows 95 are described in the Windows 95 SDK and DDK on MSDN. Windows supports using color profiles that comply with the ICC Profile Format Specification. For information, see the International Color Consortium web site at http://www.color.org.

Minimum implementation of ICC color matching requires one or more ICC profiles to be installed. Providing a monitor color calibration utility is recommended for generating, editing, and installing ICC profiles.

Eastman Kodak, the supplier of the default color matching method for ICM in Windows 95, has a wide array of advanced color management technology and products including device profiles which can be used to optimize your system. For contact information, see the "References for Video Components" section at the end of this chapter.

For PC 97, this is a recommendation for LCD, color plasma displays, or other flat panel devices. This will become a requirement.

27. Ergonomic timing standards: 75 Hz for 1024x768, minimum

Required

Recommended: 85 Hz for 1024x768.

The monitor must, at a minimum, support the ergonomic timings documented in VESA and Industry Standards and Guidelines for Computer Display Monitor Timing v. 1.0, revision 0.6 or higher, for all resolutions supported by the monitor (based on monitor size, as cited earlier in this section). The standards ensure a clear, flicker-free monitor display for traditional PC computing.

28. External monitor meets DDC 2.0 Level B and EDID standards

Required

This requirement is based on the Display Data Channel Standard v. 2.0, Level B (DDC2B), which defines the communication channel between the display and host system, and Extended Display Identification Data Standard 2.0 or higher, which defines data formats for configuration information. This requirement includes the following standards:

  • The identification string and other EDID data that the monitor sends to the system.
  • The pull-up resistor on the data clock (SCL) line.

29. All general device requirements for video components

Required

These are defined in the "Video Components Basic Requirements" and "PC 97 Design for Video Components" sections earlier in this chapter.

Note Monitor support for Windows is installed using a Monitor INF file, as defined in the Windows 95 and Windows NT DDKs.


Entertainment Monitor Requirements

A large monitor for use with an entertainment PC system requires a picture tube ideal for both PC graphics and television/movie video. This section defines the requirements for large-screen entertainment monitors.

Although an entertainment monitor is not required for Entertainment PC 97, a large (20" or greater) monitor that is sold with an Entertainment PC 97 system must meet the requirements defined in this section.

30. Large-screen monitor size: 20" or larger, if present in PC system

Required

Recommended: 31" or 33" (measured on the diagonal).

31. Support 800x600 at 60 Hz refresh rate

Required

DVD movies and typical satellite digital broadcasters provide main level/main profile MPEG-2 streams, which is the middle level of the five possible levels of MPEG-2 – encoded video data. This translates to 720x480x30 fps for NTSC. For PAL, this translates to 720x576x25 fps. Consequently, 800x600 is the optimal resolution.

Recommended refresh rate: An integral multiple of the video frame rate, for any mode in which video is displayed full screen.

For PAL, this is an integral multiple of 25 Hz. For NTSC, this is an integral multiple of 30 Hz, with an ideal rate of 120 Hz to support 24 – 30 fps content. Because most broadcast video content (such as NTSC or satellite MPEG-2 video and film) is created or adjusted through temporal rescaling or pulldown (at a 3:2 ratio) expressly for 60-Hz television monitors, further pulldown to other refresh rates (such as 72 Hz) will introduce unacceptable motion artifacts, such as non-linear screen motion.

32. Monitor meets current DDC2B and EDID standards

Required

This is the same requirement as for desktop monitors.

33. DDC2B-compliant host control and digitally controlled geometry

Required

The host control of the monitor should be managed using DDC2B-compatible adapters and drivers. This requirement is based on the Display Data Channel Standard 2.0, which defines the communication channel between the display and host system.

Geometry control is necessary for adjustment of PC-TV images, and includes these controls: skew, pin cushion, size, brightness, contrast, and position. Geometry control must be provided through a software application, rather than through dials on the monitor case. Controls must be revealed through a driver with a remote-controllable user interface.

34. ICC color matching support

Required

This is the same requirement as for desktop monitors.


Design Note for Dot Pitch Limits

Dot pitch requirements are not specified in this version of PC 97, because dot pitch depends on resolution and size. Also, design features other than dot pitch contribute to usability for PC applications, such as focus and phosphor. However, the following table defines limits depending on monitor size.

Microsoft might add a dot pitch requirement based on image tests in a later version of these specifications.

800x600 Dot Pitch Limits

Monitor size (inches) Actual size (inches) Horizontal size (inches) Vertical size (inches) Maximum dot pitch (mm)

13.00 | 11.74 | 9.39 | 7.04 | 0.30
14.00 | 12.72 | 10.18 | 7.63 | 0.32
15.00 | 13.70 | 10.96 | 8.22 | 0.35
17.00 | 15.66 | 12.53 | 9.40 | 0.40
21.00 | 19.58 | 15.66 | 11.75 | 0.50
25.00 | 23.50 | 18.80 | 14.10 | 0.60
27.00 | 25.46 | 20.37 | 15.28 | 0.65
31.00 | 29.38 | 23.50 | 17.63 | 0.75
33.00 | 31.34 | 25.07 | 18.80 | 0.80
35.00 | 33.30 | 26.64 | 19.98 | 0.85
37.00 | 35.26 | 28.21 | 21.16 | 0.90


References for Video Components

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Windows NT DDK, Windows 95 DDK, and DirectX DDK

Microsoft Developer Network (MSDN)

Display Data Channel Standard 2.0 (includes VBE/DDC)
Extended Display Identification Data Standard 2.0 (or higher)
VESA and Industry Standards and Guidelines for Computer Display
Monitor Timing

Video Electronics Standards Association
2150 North First Street, Suite 440
San Jose, CA 95131-2029 USA
Phone: (408) 435-0333
Fax: (408) 435-8225
http://www.vesa.org

International Color Consortium
ICC Profile Format Specification

http://www.color.org

Eastman Kodak, Attn: Color Management Group

164 Lexington Road
Billerica, MA 01821 USA
Phone (North America only): (800) 752-6567

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm


Checklist for Video Components

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Video Components

1. DDC 2.0 Level B-compliant color display with unique EDID identifier

Required Required Required

2. System supports MPEG-1 playback

Required Required Required

3. PC 97 DVD playback requirements, if PC system includes DVD-Video

Required with DVD-Video Required with DVD-Video Required

4. Video input and capture

Recommended Recommended Recommended


Video Components Basic Requirements

5. General device requirements

Required


PC 97 Design for Video Components

Plug and Play and Bus Design for Video Components

6. Plug and Play device identifier

Required

7. Conflict resolution and dynamic disable capabilities

Required

8. Dependent MPEG device is not enumerated independently

Required

Power Management for Display Devices

9. Compliance with Device Class Power Management Reference Specification

Required

10. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

Device Driver and Installation for Video Components

11. Device driver and installation meet Windows and Windows NT standards

Required

12. Applications provided with device meet Windows standards

Required


MPEG-1 Playback Requirements

13. Audio and video decode performance: 30 fps, minimum

Required Required Required

14. Graphics support for color space conversion and arithmetic stretching

Required Required Required


DVD Playback Requirements

15. PC 97 DVD playback requirements

Required with DVD Required with DVD Required

16. No dropped or duplicated frames

Recommended Recommended Required

Basic PC 97 Workstation PC 97 Entertainment PC 97

17. Background tasks do not interfere with DVD playback

Recommended Recommended Required

18. Subpicture compositing, if DVD drive supports video discs

Required

19. All general device requirements for video components


Video Capture Requirements

20. Wave audio capture

Recommended

21. Synchronized audio and video capture clocks

Recommended

22. Time code reading

Recommended

23. WDM imaging minidriver

Required

24. All general device requirements for video components

Required


Desktop Monitor Requirements

25. Minimum graphics resolution, based on monitor size

Required

26. ICC color matching support

Required
Recommended for LCD

27. Ergonomic timing standards: 75 Hz for 1024x768, minimum

Required

28. External monitor meets DDC 2.0 Level B and EDID standards

Required

29. All general device requirements for video components

Required


Entertainment Monitor Requirements

30. Large-screen monitor size: 20" or larger, if present in PC system

Required

31. Support 800x600 at 60 Hz refresh rate

Required

32. Monitor meets current DDC2B and EDID standards

Required

33. DDC2B-compliant host control and digitally controlled geometry

Required

34. ICC color matching support

Required


Chapter 17 Audio Components

This chapter presents the requirements and recommendations for audio devices under the Microsoft Windows family of operating system.


Overview for Audio Components

For PC 97, the important design issues for basic audio under Microsoft Windows are to ensure a complete Plug and Play experience for end users and to ensure that audio capabilities meet minimum standards.

Microsoft DirectSound technology provides APIs for low-latency mixing, hardware acceleration, and direct access to the sound device, while maintaining compatibility with earlier Windows-based applications and device drivers. DirectSound provides a device-independent interface that application developers can use to take advantage of any hardware capabilities. The device driver reports the capabilities of the hardware to DirectSound and passes DirectSound requests to the hardware.

Note For additional Entertainment PC 97 and DVD-related audio requirements, see the section on DVD playback requirements in the "Video Components" chapter in Part 4 of this guide.


System Requirements for Audio Components

This section summarizes the hardware requirements for audio for PC 97 system designs.

1. Baseline audio meets PC 97 requirements

Basic PC 97 | Workstation 97 | Entertainment PC 97
Recommended | Recommended | Advanced audio Required

If baseline audio capabilities are included in a PC system, audio must meet the minimum requirements defined in "Basic Requirements for Audio Components" in this chapter.

2. PC 97 Advanced audio capabilities included in the PC system

Basic PC 97 | Workstation 97 | Entertainment PC 97
Recommended | Recommended | Required

Each feature for Advanced audio that is implemented in a PC 97 system must meet the minimum requirements for that feature as defined in "PC 97 Advanced Audio" in this chapter.


Basic Requirements for Audio Components

This section defines requirements for basic hardware features for audio components and the specific features for PC 97. Device performance is measured by the WHQL Audio Compatibility Tests (ACT). ACT currently measures performance of the driver/hardware combination for opening, closing, and resetting the device.

Note WHQL compatibility tests are revised quarterly. To ensure that you have the most recent ACT, see http://www.microsoft.com/hwtest/outtest.htm.


Baseline Audio for PC 97

This section defines the requirements for baseline audio, which is typically implemented as a system board solution for business PCs. Although audio is not required on a PC 97 Basic or Workstation system, if baseline audio is implemented in the system it must meet the requirements defined in this section.

3. General device requirements for PC 97

Required

These include the standard PC 97 requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information, see the "Basic PC 97" chapter in Part 2 of this guide.

4. Minimum standards for output

Required

  • 16-bit digital-to-analog converter (DAC)
  • Support for monaural output

    Recommended: Support for stereo (required for PC 97 Advanced audio)

  • Support for 8-bit and 16-bit linear pulse-code modulation (PCM) digital audio
  • Required sampling rates: 8 kHz, 11.025 kHz, 22.050 kHz, and 44.1 kHz

    Recommended sampling rates: 16 kHz, 32 kHz, and 48 kHz (required for PC 97 Advanced audio)

  • Support for MIDI playback; if implemented as music synthesis, the minimum support must include 16 voices plus 6 timbres for basic audio

5. Minimum standards for input

Required

  • 16-bit analog-to-digital (A/D) converter
  • Support for monaural input

    Recommended: Support for stereo (required for PC 97 Advanced audio)

  • Support for 8-bit and 16-bit input
  • Required sampling rates: 8 kHz, 11.025 kHz, 22.050 kHz, and 44.1 kHz

    Recommended sampling rates: 16 kHz, 32 kHz, and 48 kHz (required for PC 97 Advanced audio)

6. One line out and one line in, minimum

Required

At a minimum, the system must include support for one line in and one line out. The minimum line-in support can include 3.5-mm microphone in or 3.5-mm line in. The minimum line-out support can include 3.5-mm headphone out, line out, or speaker out.

Typically, a baseline audio implementation will include additional line-in/line-out support, but this bare minimum is defined to allow alternate solutions for designs sensitive to form-factor issues.

7. Minimum audio performance characteristics

Basic PC 97 | Workstation 97 | Entertainment PC 97
Required | Required | Required

The following is required for input (record) and output (playback):

  • 75 dB signal-to-noise ratio (SNR).
  • Frequency response: 20 Hz to 20 kHz, A-weighted.

    For mobile PCs, the signal-to-noise requirement is 75 dB from 20 Hz to 15 kHz, A-weighted.

  • 0.02 per cent total harmonic distortion.

Signal-to-noise (S/N) ratio is defined as the ratio of the RMS output level with 1 kHz full scale input to the RMS output level with all zeros into the digital input (AES17-1991).


PC 97 Advanced Audio

This section defines the guidelines for PC 97 Advanced audio, including guidelines for hardware acceleration features.

Note The requirements in this section do not apply if baseline audio is implemented on the system board. Notice also that if any component of PC 97 Advanced audio is implemented in a system, it must meet the standards defined in this section for that component.

8. Advanced audio meets additional standards for input and output

Basic PC 97 | Workstation 97 | Entertainment PC 97
Required | Required | Required

The requirements for minimum input and output standards are defined in the "Baseline Audio for PC 97" section in this chapter. The following lists the additional related requirements for PC 97 Advanced audio:

  • Line in and line out capabilities and DAC support must be stereo.
  • Additional required sampling rates for both input and output: 16 kHz, 32 kHz, and 48 kHz.
  • Minimum input capabilities must include 3.5-mm microphone.
  • Minimum audio performance characteristics:
  • 75 dB SNR for input; 85 dB SNR for output.
  • 90 dB analog signal path SNR through mixer.
  • Frequency response: 20 Hz to 20 kHz, A-weighted.
  • 0.02 per cent total harmonic distortion.

9. Full duplex operation

Basic PC 97 | Workstation 97 | Entertainment PC 97
Required | Required | Required

The PC 97 Advanced audio subsystem must support full duplex operation for simultaneous encoding and decoding of audio data, enabling audio playback while simultaneously supporting audio input.

10. Input and output support independent sampling rates

Basic PC 97 | Workstation 97 | Entertainment PC 97
Recommended | Recommended | Required

The input (A/D) and output (D/A) portions of the audio subsystem should support independent sampling rates. For example, the audio playback could be set at 44.1 kHz for high-quality audio while the microphone input is sampled at 8 kHz to support a conferencing application.

11. Support sample position for stream synchronization

Basic PC 97 | Workstation 97 | Entertainment PC 97
Required | Required | Required

This means that the driver must be capable of returning an accurate indication of the current position in the buffer being rendered. Sample accuracy is in relation to the samples given to the codec. Accurate reporting of the current position in the buffer being rendered means reporting position within 1 ms. This will apply for compressed or uncompressed data.

12. Support for music synthesis

Basic PC 97 | Workstation 97 | Entertainment PC 97
Recommended | Recommended | Required

Recommended: Hardware support for downloadable samples.

A software or hardware solution can be implemented. This includes supporting, at a minimum, standard MIDI 24-voice polyphony plus 16 timbres for PC 97 Advanced audio.

13. Support for echo cancellation

Basic PC 97 | Workstation 97 | Entertainment PC 97
Recommended | Recommended | Required

Recommended: Hardware provides reference signals on two channels (mono in, mono out).

This feature allows the user to remove speaker content from the incoming microphone input stream. For example, if the user has other audio output mixed with the incoming voice in an audio-conferencing or multiplayer application, all speaker content is removed from the input microphone stream.


PC 97 Design for Audio

This section summarizes requirements related to the design initiatives for PC 97 defined in Part 1 of this guide.


Plug and Play for Audio

The items in this section are requirements for all PC 97 systems that implement audio in any form.

14. Plug and Play device identifier

Required

  • For a non-bus-specific system board device, there must be a device-specific identifier.
  • Each bus-specific device must have a Plug and Play device identifier as required for the bus it uses, as defined in Part 3 of this guide. For example, a PCI device must comply with PCI v. 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide.

Note Each separate device or function that is enumerated by the BIOS on an audio adapter must have a separate Plug and Play device ID and separate resource configuration. If a game port or CD-ROM interface is supplied, resources must be allocated in addition to those required for the audio device. Such devices must also have independent dynamic disable capabilities. For complete information about requirements and exceptions for multifunction cards under PC 97, see the "Basic PC 97" chapter in Part 2 of this guide.

15. Automatic resource assignment and dynamic disable capabilities

Required

The system must be capable of automatically assigning, disabling, and relocating the resources used by this device when necessary, using the method required for the related bus class. All configuration settings must be capable of being made through software, with no system reboot required. Changing or adding this device to the system must not require changing jumpers or switches on either the adapter or the system board to set resource assignments. In the event of an irreconcilable conflict with other devices on the system, the system must be able to disable the device to prevent the system from stalling. The device must not claim any resources while disabled.


Requirements for ISA Devices

This section defines requirements if the audio device uses ISA. However, ISA is not a recommended solution for supporting audio in a PC 97 system.

16. Unique 16-bit address for I/O decode

Required

As for all PC 97 devices, this is required for both onboard and add-on devices. For information, see the "Basic PC 97" chapter in Part 1 of this guide.

17. Minimum resource requirements

Required

These are the required resource settings for ISA devices:

  • 4 unique I/O locations

    Recommended: 7 I/O locations

  • 4 unique IRQ signals

    Recommended: 7 IRQ signals

  • 3 DMA channel selections, if DMA is used

    Recommend: 16-bit F-mode DMA

Note Type F DMA is strongly recommended for system-board audio implementations or for add-on devices that use ISA.

18. Unique IDs include Serial Number field for each ISA card

Recommended

Unique IDs with Serial Number fields ensure correct support for multiple instances of the same device type. If unique serial numbers are not supported, the Serial Number field must contain 0xFFFFFFFF, as required in the ISA Plug and Play specification. For more information, see the "ISA" chapter in Part 3 of this guide.


Requirements for PCI Devices

This section defines the hardware requirements if the audio device uses PCI.

19. PCI v. 2.1 (or higher) and additional PC 97 requirements

Required

If the device uses PCI, it must meet the requirements defined in the "PCI" chapter in Part 3 of this guide, including requirements for providing a Subsystem ID and Subsystem Vendor ID.

20. Initiator, target, and block transfer support

Required

For complete implementation details, see the PCI v. 2.1 specification.

21. PCI audio components comply with ISA Plug and Play requirements if using ISA resources

Required

Any PCI audio components that use any ISA resources such as DMA, IRQ, or I/O addresses must meet all Plug and Play requirements for ISA, including dynamic disable capabilities, as defined in the "ISA" chapter in Part 3 of this guide. PCI devices on the system board do not have to provide relocatable I/O addresses for the following legacy I/O registers:

Sound Blaster register (220h – 22Fh)
FM synthesis register (388h – 38Bh) 		MPU-401 register (330h – 331h)
WSS-compatible register (534h – 537h)


Requirements for USB Devices

This section defines requirements if the audio device uses USB.

22. USB Specification and USB audio device class specifications

Required

This device must comply with the Universal Serial Bus Specification (v. 1.0 or higher) and the related USB device class specification. This ensures that all Plug and Play requirements are met and that Microsoft drivers support this device.


Requirements for IEEE 1394 Devices

This section defines requirements if the audio device uses IEEE 1394.

23. Advanced audio meets PC 97 requirements for IEEE 1394

Required

For requirements related to IEEE 1394 peripherals, see the "IEEE 1394" chapter in Part 3 of this guide.


Power Management for Audio Components

This section summarizes the specific power management requirements for audio components.

24. Compliance with "Device Class Power Management Reference Specification" for audio devices

Required

The "Device Class Power Management Reference Specification" for audio provides definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class. Power states D0 and D3 are required. Other power states are recommended.

25. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for audio devices is an optional feature.


Device Drivers and Installation for Audio Components

This section summarizes requirements for device drivers for audio. The items in this section are required for all PC 97 systems.

26. Device driver and installation meet Windows and Windows NT standards

Required

The manufacturer does not need to supply a driver if a standard driver provided with the operating system can be used. If the manufacturer supplies drivers, the requirements include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry.
  • The correct minidriver, VxD, and any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations.
  • Driver installation and removal use Windows-based methods as defined in the Windows 95 and Windows NT DDKs.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).
  • If support using WDM drivers is provided in the operating system, the driver supplied by the manufacturer must be a WDM driver.

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.

27. Applications provided with device meet Windows standards

Required

Any Windows-based applications provided with the device must meet Microsoft requirements for software compatibility as indicated by the "Designed for Microsoft Windows" logo.


References for Audio

The following presents some of the references, services, and tools available to help build hardware that works with Windows operating systems.

WHQL Audio Compatibility Tests

http://www.microsoft.com/hwtest/outtest.htm

Current information on audio design and Windows support

http://www.microsoft.com/hwdev/devdes/

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Windows 95 DDK, Windows NT DhDK, and DirectX DDK

MSDN Professional membership


Checklist for Audio

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Audio Components

1. Baseline audio meets PC 97 requirements

Recommended Recommended Advanced audio required

2. PC 97 Advanced audio capabilities included in the PC system

Recommended Recommended Required


Basic Requirements for Audio Components

Baseline Audio for PC 97

3. General device requirements for PC 97

Required

4. Minimum standards for output

Required

5. Minimum standards for input

Required

6. One line out and one line in, minimum

Required

7. Minimum audio performance characteristics

Required Required Required

PC 97 Advanced Audio

8. Advanced audio meets additional standards for input and output

Required Required Required

9. Full duplex operation

Required Required Required

10. Input and output support independent sampling rates

Recommended Recommended Required

11. Support sample position for stream synchronization

Required Required Required

12. Support for music synthesis

Recommended Recommended Required

13. Support for echo cancellation

Recommended Recommended Required


PC 97 Design for Audio

Plug and Play for Audio

14. Plug and Play device identifier

Required

15. Automatic resource assignment and dynamic disable capabilities

Required

Requirements for ISA Devices

16. Unique 16-bit address for I/O decode

Required

17. Minimum resource requirements

Required

18. Unique IDs include Serial Number field for each ISA card

Recommended

Requirements for PCI Devices

19. PCI v. 2.1 (or higher) and additional PC 97 requirements

Required

20. Initiator, target, and block transfer support

Required

21. PCI audio components comply with ISA Plug and Play requirements if using ISA resources

Required

Requirements for USB Devices

22. USB Specification and USB audio device class specifications

Required

Requirements for IEEE 1394 Devices

23. Advanced audio meets PC 97 requirements for IEEE 1394

Required

Power Management for Audio Components

24. Compliance with "Device Class Power Management Reference Specification" for audio devices

Required

25. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

Device Drivers and Installation for Audio Components

26. Device driver and installation meet Windows and Windows NT standards

Required

27. Applications provided with device meet Windows standards

Required


Chapter 18 Storage and Related Peripherals

This section presents the requirements for storage and related peripherals, including DVD devices, under the Microsoft Windows family of operating systems.

Specific requirements for SCSI, IDE, and ATAPI peripherals are defined in the related chapters in Part 3 of this guide.


System Requirements for Storage Peripherals

This section summarizes both the basic hardware design features for storage peripherals and the specific features for PC 97.


Storage Peripherals Basic Features

This section summarizes the hardware requirements for storage peripherals.

1. Bus master capabilities

Recommended for hard disk controller and CD-ROM
Required for DVD-ROM

Bus master capabilities, if implemented, must meet the related specification for the particular controller. For example, the programming register set for PCI IDE bus master DMA is defined in Small Form Factor (SFF) 8038i.

Correctly implemented bus master support ensures improved performance and Windows-compatible device driver support.

Note This recommendation will become a requirement in 1998. This recommendation does not apply to legacy floppy disk controllers (FDC) and will not become a requirement for the FDC.

2. Media status notification support for removable media

Required

IDE removable storage devices must follow the Microsoft specification named Media Status Notification v. 1.03 or higher. SCSI removable devices must follow the Media Status Notification Specification for SCSI and ATAPI Devices (v. 1.0 or higher).

3. Support Int 13h Extensions in option ROMs

Required

The Int 13h Extensions ensure correct support for high-capacity drives, consistent drive-letter mapping between real mode and protected mode, and other capabilities for both Windows 95 and Windows NT. Support for the "fixed disk access" subset of Int 13h Extensions must be provided in the system BIOS and in any option ROMs for storage devices that include BIOS support. The Int 13h Extensions are defined in "Int 13x Extension APIs" in the Layered Block Device Drivers section of the Windows 95 DDK.

4. General device requirements

Required

These include the standard requirements for a Plug and Play device identifier, automated software-only settings for device configuration, standard device drivers and Windows-based installation, and icons for external connectors. For more information, see the "Basic PC 97" chapter of this guide.

5. Device meets requirements for port or bus

Required

The device must meet all requirements for the port or bus to which it is attached. For example, a drive that uses the parallel port must meet all the requirements defined for legacy parallel peripherals (including requirements for ECP mode), as defined in the "Serial, Parallel, and Wireless Support" chapter in this guide. If the device uses a PCI, IDE, or SCSI connection, the device must meet the related requirements defined in Part 3 of this guide.

6. Easy installation for end user

Recommended

Ease-of-use requirements for installation and configuration are defined for SCSI peripherals and for IDE and ATAPI devices in Part 3 of this guide.


PC 97 Design for Storage Components

This section summarizes requirements related to Plug and Play and other bus- and resource-related design issues for storage devices.


Plug and Play and Bus Design for Storage Components

The items in this section are requirements for Plug and Play capabilities.

7. Plug and Play device identifier

Required

  • For a non-bus specific system board device, there must be a device-specific identifier.
  • Each bus-specific device must provide Plug and Play device identifiers in the manner required for the bus it uses, as defined in Part 3 of this guide. For example, a PCI add-on device must comply with PCI 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide.

8. Conflict resolution and dynamic disable capabilities

Required

To ensure conflict resolution for resource allocation, the device must conform to the Plug and Play specifications for the bus it uses as described in Part 3 of this guide. The system must have a method for automatically disabling or relocating the resources used by the device if conflicts occur when an expansion card is added to the system.

Devices must be capable of being disabled with software settings only — that is, without requiring rebooting or jumper setting changes. Disabling the device must result in freeing all of its resources for use by other devices. DIP switches on boot devices can be used for an initial power-on default state or for non – Plug and Play system compatibility, but must be able to be overridden by software configuration after system power up.

The primary hard disk controller is an exception to the requirement for dynamic disable capabilities.

9. 3F7h and 377h unclaimed by devices

Required

To avoid having two devices in the system claim 3F7h and 377h, these addresses should not be claimed as resources in device registers, especially by IDE devices.

It is recognized that some FDC devices claim this range. Such devices can be implemented in a PC 97 system; however, the system manufacturer must ensure that only a single device in the system claims this range.


Power Management for Storage Components

This section summarizes the specific power management requirements for storage devices.

10. Compliance with "Device Class Power Management Reference Specification"

Required

The "Device Class Power Management Reference Specification" for the storage device class provides definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class. Power states D0 and D3 are required.

11. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for the storage device class is an optional feature.


Device Drivers and Installation for Storage

This section summarizes the basic requirements for device drivers and installation procedures for storage devices.

12. Device driver and installation meet Windows and Windows NT standards

Required

Each device requires drivers for both Windows 95 and Windows NT operating systems. The manufacturer does not need to supply a driver if a standard driver provided with the operating system can be used. If the manufacturer supplies drivers, the requirements for device drivers and installation include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in registry.
  • The correct minidriver, VxD, or any other files specified in the device's INF must be installed in the correct locations.
  • Driver installation and removal use Windows-based methods as defined in the Windows 95 and Windows NT DDKs.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).
  • If support using WDM drivers is provided in the operating system, the driver supplied by the manufacturer must be a WDM minidriver.

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.

13. Device and file system run in protected mode after installation

Required

The device driver and the file system must be running in 32-bit, protected mode (not "compatibility mode") immediately after installation.

14. Applications provided with the device meet Windows standards

Required

Any Windows-based applications provided with the device must meet Microsoft requirements for software compatibility, as indicated by the "Designed for Microsoft Windows" logo. However, any software applications included with the device can be installed using an alternate Windows-based installation method as defined in the Win32 SDK.

15. Device driver for partitioned media supports FAT32 partitions

Required

Device drivers that support partitioned media must support the new FAT32 partition types (0xB and 0xC), in addition to the Extended Int 13h partition types (0xF and 0xE).

16. Block-mode device driver supports extended BPBs

Required

Storage subsystems that include an MS-DOS – based block mode device driver (for example, Aspidisk.sys) must support Extended BIOS Parameter Blocks (BPBs) in the Build BPB device driver function call and support category=48 in the generic IOCTL device driver interface calls, as specified in the mid-1996 update to the Windows 95 DDK.


Floppy Disk Drive Controller

This section describes the requirements for any floppy disk controller (FDC) provided with a PC 97 system.

A floppy disk controller is not a requirement for a PC 97. Although most systems include some form of floppy disk drive, some systems such as diskless workstations do not need one.

17. Floppy disk capabilities provided through expansion card or external bus

Recommended

To support migration away from legacy devices for PC 97, it is recommended that support for floppy disk drives be provided by using a solution based on an external bus such as USB, PC Card, or an expansion card for SCSI or IDE.

18. Legacy floppy disk controller built into system

Optional

If a legacy FDC is included on a PC 97 system, it must meet the requirements listed in this section.

19. FDC compliant with all general storage device requirements

Required

These are defined in the "System Requirements for Storage Peripherals" section earlier in this chapter.

20. Resource configuration for legacy FDC device

Required

The resource requirements must be met for each device of this type on the system, not shared among devices of the same type.

  • Use static I/O addresses 3F2h, 3F4h, and 3F5h. Additional addresses can be provided in the event of conflict.
  • Use IRQ 6.
  • Use DMA Channel 2 if the FDC supports block data transfers to memory using the DMA controllers.

21. Conflict resolution and dynamic disable capabilities for legacy FDC

Required

The FDC must be capable of being disabled. For example, if the FDC is located on the system board and an adapter card that includes an FDC is added to the system, the system-board FDC must be capable of being disabled to prevent conflicts with the new card. If the FDC is located on an expansion card, the expansion card must allow independent dynamic disabling of the FDC and the hard disk controller (HDC). In this case, the adapter will continue to function if the FDC is disabled because of conflicts, and vice versa.


Hard Disk Drives

This section summarizes specific requirements for hard disk drives.

Note In the "ATA and ATAPI" chapter in Part 3 of this guide, BIOS support is required for a logical block addressing (LBA) scheme compatible with the BIOS/CMOS and IDE register set constraints. This enables support for IDE disk drives larger than 528 MB.

22. Compliant with all general storage device requirements

Required

These are defined in the "System Requirements for Storage Peripherals" section earlier in this chapter.

Note The recommendation for bus mastering for hard disk controllers will become a requirement in 1998.

23. Drive spin-up time supports OnNow capabilities

Recommended

The hard disk drive should spin up and be able to complete a Read operation within six seconds of applying power and within three seconds of leaving the ATA Standby Immediate mode.

This recommendation supports the OnNow design initiative goals for a system that is "instantly" available when power is applied.

24. IDE drive supports M, S, and CS settings

Required

The IDE hard disk drive must be configurable as Master, Slave, or Cable Select.


CD-ROM Peripherals

This section summarizes the requirements for CD-ROM peripherals and the specific features for PC 97.

25. Compliant with all general storage device requirements

Required

These are defined in the "System Requirements for Storage Peripherals" section earlier in this chapter.

Note The recommendation for bus mastering for CD-ROM will become a requirement in 1998.

26. Performance: 4x or higher

Required

The CD-ROM drive must perform at this minimum level when running in the Fully On power state. However, a device can spin slower when running in lower power states, as defined in the "Device Class Power Management Reference Specification" for the storage device class.

27. CD Enhanced compatible

Required

For PC 97, the CD-ROM drive must be able to mount multisession CD-ROM disks, even if track 1 is Red Book audio. Microsoft recommends use of the Sony ReadTOC method for SCSI-2 multisession support as noted in the ATAPI SFF 8020i rev. 2.5.

CD Enhanced support must be Blue Book compliant, as defined in Enhanced Music CD Specification v. 1.0.

28. Supports required CD formats

Required

At a minimum, the CD-ROM device must be compatible with these formats to ensure cross-media compatibility:

  • Logical formats: CD Red Book, Yellow Book, White Book, and Blue Book.
  • Physical formats: CD-E, CD-R2, CD-ROM, and CD-Audio.

CD-R (Orange Book format) can be implemented. There are no PC 97 requirements or recommendations.

29. CD changer

Optional

If an ATAPI-compatible CD changer is present (seven discs or less capacity), the device must be compliant with ATAPI SFF 8020i v. 2.6 or higher.

30. System BIOS supports El Torito No Emulation mode if CD-ROM is the boot device

Required

For PC systems that use CD-ROM as the boot device, the system BIOS must support the No Emulation mode defined in the specification "El Torito — Bootable CD-ROM Format Specification Version 1.0," published by IBM and Phoenix.


Rewritable ATAPI Devices

This section summarizes specific requirements for optical storage devices.

31. Compliant with all general storage device requirements

Required

These are defined in the "System Requirements for Storage Peripherals" section earlier in this chapter.

32. Compliant with SFF 8020i v. 2.6 or higher

Required

This specification defines the requirements for ATAPI rewritable devices, including specifications for LUN implementation, media status notification, and device write protection.

33. Support Read Format Capacities command

Required

This requirement is defined in SFF 8020i v. 2.6.


DVD Devices

This section summarizes specific requirements for DVD devices.

The industry is currently involved in defining standards for DVD. Microsoft is working with the industry to define a command set for DVD. When this command set is adopted in the industry, support for this command set will be required for PC 97.

34. Compliant with all general storage device requirements

Required

These are defined in the "System Requirements for Storage Peripherals" section earlier in this chapter.

Note Bus mastering for DVD-ROM is a requirement for PC 97.

35. Meets minimum compatibility requirements

Required

At a minimum, the DVD device must be compatible with these formats to ensure that earlier media can be read by the DVD device:

  • Logical formats: CD Red Book, Yellow Book, White Book, and Blue Book.
  • Physical formats: CD-R2, CD-ROM, CD-Audio, and DVD-ROM.

36. Compliant with command sets for DVD

Required

The device must be compliant with SFF 8020i v. 3.0 or higher for ATAPI DVD-ROM drivers. Specifications for SCSI or IEEE 1394 DVD-ROM drives are yet to be defined.

37. High-speed expansion bus

Required

The DVD hardware must use a bus that supports high-speed transfer of multiple data types. Any DVD controller must be capable of sustained rates of 12 megabits per second at a minimum.

38. System supports PC 97 DVD playback requirements, if DVD drive support video discs

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Required with DVD-Video | Required with DVD-Video | Required

Systems that support video discs must be capable of properly decoding and displaying or playing the appropriate data streams. For information about the PC 97 required support for DVD playback, see the "Video Components" chapter in Part 4 of this guide.

39. File system accessible from the Windows operating system

Required

The drive will support Universal Disk Format (UDF) as defined in the DVD Alliance specification.

40. Push-to-close design, if motorized capabilities are included

Required

A motorized design is not required, but if it is implemented, the device must be designed so the user has three options to close the device when inserting a disc:

  • Physically push on the bay
  • Physically push the close button on the bay housing
  • Select software-supported option to close the device

41. Defect management

Required

The drive must support defect management that is transparent to the operating system according to industry standards.

42. Copy protection

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

The drive should support the copy protection of movie and software content.


References and Resources for Storage

This section lists resources for building storage hardware that works with the Windows operating system.

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Microsoft Media Status Notification specifications

http://www.microsoft.com/hwdev/specs/

Multisession Compact Disc Specification

Enhanced Music CD Specification v. 1.0

Philips Consumer Electronics B.V.
Coordination Office Optical – Magnetic Media Systems
Building SWA-109, P.O. Box 80002
5600 JB Eindhoven, The Netherlands
Fax: (31) (40) 732113

Sony/Philips CD-ROM hardware logo program:
Bert Gall, Philips Consumer Electronics
Philips Consumer Electronics B.V.

IDE and SCSI Interface Specifications

Global Engineering Documents
U.S. and Canada: (800) 854-7179
Other locations: (303) 792-2181
Fax: (303) 792-2192

ATA 2 [X3T9.2 948D]
ATA Packet Interface for CD-ROMs, SFF 8020i
Small Computer Interface (SCSI-2)
Small Computer Interface (SCSI-3) Parallel Interface (SPI)

Small Form Factor Committee (SFF) Publications
FaxAccess: (408) 741-1600 (fax-back)

Windows 95 DDK and Windows NT DDK

MSDN Professional membership.
The Windows 95 DDK includes the "Int 13h Extensions API."

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm

Device driver support for FAT32 partitions

http://www.microsoft.com/hwdev/devdes/fat32.htm


Checklist for Storage

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Storage Peripherals

Storage Peripherals Basic Features

1. Bus master capabilities

Recommended for hard disk controller and CD-ROM
Required for DVD-ROM

2. Media status notification support for removable media

Required

3. Support Int 13h Extensions in option ROMs

Required

4. General device requirements

Required

5. Device meets requirements for port or bus

Required

6. Easy installation for end user

Recommended

PC 97 Design for Storage Components

7. Plug and Play device identifier

Required

8. Conflict resolution and dynamic disable capabilities

Required

9. 3F7h and 377h unclaimed by devices

Required

10. Compliance with "Device Class Power Management Reference Specification"

Required

11. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

12. Device driver and installation meet Windows and Windows NT standards

Required

13. Device and file system run in protected mode after installation

Required

14. Applications provided with the device meet Windows standards

Required

15. Device driver for partitioned media supports FAT32 partitions

Required

16. Block-mode device driver supports extended BPBs

Required


Floppy Disk Drive Controller

17. Floppy disk capabilities provided through expansion card or external bus

Recommended

18. Legacy floppy disk controller built into system

Optional

19. FDC compliant with all general storage device requirements

Required

20. Resource configuration for legacy FDC device

Required

21. Conflict resolution and dynamic disable capabilities for legacy FDC

Required


Hard Disk Drives

22. Compliant with all general storage device requirements

Required

23. Drive spin-up time supports OnNow capabilities

Recommended

24. IDE drive supports M, S, and CS settings

Required


CD-ROM Peripherals

25. Compliant with all general storage device requirements

Required

26. Performance: 4x or higher

Required

27. CD Enhanced compatible

Required

28. Supports required CD formats

Required

29. CD changer

Optional

30. System BIOS supports El Torito No Emulation mode if CD-ROM is the boot device

Required


Rewritable ATAPI Devices

31. Compliant with all general storage device requirements

Required

32. Compliant with SFF 8020i v. 2.6 or higher

Required

33. Support Read Format Capacities command

Required


DVD Devices

34. Compliant with all general storage device requirements

Required

35. Meets minimum compatibility requirements

Required

36. Compliant with command sets for DVD

Required

37. High-speed expansion bus

Required

38. System supports PC 97 DVD playback requirements, if DVD drive support video discs

Required with DVD-Video Required with DVD-Video Required

39. File system accessible from the Windows operating system

Required

40. Push-to-close design, if motorized capabilities are included

Required

41. Defect management

Required

42. Copy protection

Recommended Recommended Required


Chapter 19 Modems

This chapter presents the requirements for serial modems, fax modems, voice modems, and voice/data modems under the Microsoft Windows family of operating systems.


Overview for Modems

This section presents the key design issues for modems. The Windows operating systems and Win32-based applications use data, fax, voice, and voice/data integration features in modems.

Basic PC 97 modem. The fundamental design principle for compatibility with Windows is for the device to be supported by the Universal Modem Driver (Unimodem), which uses INF files to characterize the behavior of a device. The detailed definition of Unimodem requirements is contained in the Modem Developers Kit (MDK). Future changes will include migration of functions from the device driver into the Windows operating systems and the Win32 Driver Model (WDM).

Also for PC 97, these are the basic design concerns for modems:

  • Better Internet access and communications speed. The requirement is for double the speed over that specified for PC 95 (V.34, 28.8 Kbps).
  • Better power management. This is both an OnNow design initiative and "Green PC" issue.
  • Better installation for improved user experience. This includes requirements for standard commands to allow adaptive installation.
  • Required support for data and fax capabilities.
  • Recommended support for adaptive connection and standard voice/data, including PC-based video telephony.
  • Recommended support for Text Telephones (V.18) to support deaf users.

Voice and voice/data modems. It is only recommended that a modem include voice or voice/data integration features:

  • A voice modem communicates in either voice or data mode but does not carry both voice and data simultaneously. Voice-modem applications include telephone answering machine (TAM), automated attendant or receptionist, and interactive voice response (IVR), in addition to conventional person-to-person voice and machine-to-machine data calls. The SOHO (Small Office/Home Office) PC market is driving interest in voice modems that can converse in these various modes over a single analog (POTS) line.
  • A voice/data integration modem has the ability to mix voice, data, and optionally video (H.324) in the same call.

In some countries, these features are not yet legal. For some networks, these features are not yet supported (for example, voice/data integration on GSM digital cellular). For some installations, these features have limited utility (for example, modem pools). However, if voice or voice/data integration capabilities are included, the requirements defined in this chapter must be met.

Wireline modems. These are the design issues and recommendations for PC 97:

  • Improvements in basic data modem technology, such as V.34 up to 33.6K, V.25ter, and V.80.
  • Adaptive connection features: V.25, V.8, V.8bis, and V.25ter Annex A.
  • Support voice features, particularly for SOHO or family home use (TIA-695).
  • Voice/data integration. The ITU has recently completed work on recommendations for standard Digital Simultaneous Voice/Data (V.70-series) and Video Telephony (H.324 suite) recommendations, along with V.8bis for making the transition from simple voice to a mixed mode. For more information, see the recommendation for simultaneous voice/data integration capabilities later in this chapter.

    In mid-1996, Windows 95 included support for VoiceView, which is a transitional technology, to be followed by support for some form of Simultaneous Voice/Data technology, particularly H.324 video telephony.

Modems for mobile PC systems. The design issues for PC 97 are implementation of analog or digital cellular with standard command sets, as described later in this chapter under the recommendation for cellular phone support. In the short term, Windows and Windows NT can use mobile data and fax. In the longer term, there should be support for voice and Short Messaging Services (SMS).


System Requirements for Modems

This section summarizes the PC system requirements for modems.

1. Modem device provided with PC system

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required if no network adapter | Required; voice/data recommended

Recommended: Internal modem, or USB or PC Card as the external connection for the modem.

If the device is provided with the PC system, it must meet the minimum requirements for modems defined in this chapter.


Modem Basic Features

This section defines requirements for basic hardware features.

2. Modem command set: TIA-602, "Hayes compatible"

Required

TIA-602 codifies the most common data modem.

Recommended: ITU V.25ter, which is a superset of TIA-602 with significant and useful improvements. It includes three new components:

  • A standard format for extending the AT command set, with standard means for the PC to test the range of supported values for each command. This enables adaptive modem installation.
  • Standard extensions for modem ID, port control, modulation control and reporting, error control, and data compression control and reporting. This reduces or eliminates the need for data modem INF files.
  • Annex A (1996) provides standard commands for PC to use V.25, V.8, and V.8bis call control features. This enables point-to-point data and voice/data/video calls.

The particular utility of the standard format is that it allows a future modem installer to adaptively install and use a modem without need for INF minidrivers.

3. Data modem: 28.8 Kbps (V.34-1994) with V.42 and V.42bis protocol

Required

Recommended: 33.6 Kbps (V.34-1996).

The dominant use of data modems now is connection to Internet service providers. Web browsing is bandwidth intensive, so the more available the better.

As part of the command set, the modem must have a distinct means for controlling the reporting of modem-to-modem protocols, so the modem can be forced to generate recognizable reports for modulation, error control, and data compression. Examples include the Wn command, the S95 register, the \Vn command, or the ITU V.25ter +MR, +ER, and +DR commands.

4. Synchronous access for data modems: V.80 or similar technique

Recommended

This recommendation can be implemented using V.80 or similar proprietary techniques that provide synchronous access to enable Videophone capabilities over PSTN. ITU V.80, a PC-to-modem protocol based on V.25ter, opens the door to support standard voice/data/video communication from PC software, at minimal cost to the modem maker. It also provides mechanisms to enhance the quality of service of Internet real-time multimedia services by defining standard means for multiplexing data and modem control messages on the same port at the same time, and providing synchronous access to the PC. V.80 includes the following components:

  • Standard means for a PC and a modem to exchange the state of V.24 handshake circuits by the use of in-band messages. This is required in situations where the hardware leads for such circuits do not exist, as might be the case for digital cellular data services.
  • Standard means for using in-band messages to exchange V.25ter AT commands and indications while in OnLine Data State. It is recommended that modems support this feature. It is referenced by cellular data standards and by ongoing work in the ITU on commands for voice/data/video communications devices.
  • Standard means for providing synchronous access to the PC, with or without HDLC framing services. Synchronous Access allows video telephony or digital voice/data to be implemented in the PC. Specifically, support for the Synchronous Access Mode defined in §8/V.80 is required (for example, Transparent sub-Mode and Framed sub-Mode). To support existing and future multimedia communication services, support of the "no CRC" option in Framed sub-Mode is required. Support is required for the +ITF command, used to control buffer-induced latency in the modem.

Note If implemented on both sides of a modem connection, V.80 can be used to increase the throughput of PPP or PPTP connections by 25 per cent (delete the start-stop bits). IETF is studying proposals to make use of V.80 for that purpose.

5. Fax modem: 14.4 Kbps (V.17) with Class 1 (TIA-578-A) command set

Required

Recommended: Class 1.0 (ITU T.31) with +FAR support, which allows the hardware to perform adaptive carrier detection.

Modems continue to be useful for fax communications, particularly for sending faxes and print-to-fax. The recent ITU version of this standard includes features for improved performance in the presence of echo delays. T.31 Annex B extends to support V.34 fax, but there are few V.34 fax machines available in 1996.

6. Telephone Device for the Deaf (TDD): V.18 with V.25ter command

Recommended

TDD is also known as Text Telephones. People who are hearing impaired use Text Telephones to communicate over phone lines with both hearing and hearing impaired persons. The U.S. Americans with Disabilities Act requires all businesses of a certain size or larger to have Text Telephone services available and to be able to receive calls from people using Text Telephones.

In North America and Europe, the following types of Text Telephones are used:

  • Baudot: 45 or 50 bit/s FSK using 5-bit Baudot coding
  • "ASCII" 300 bit/s Bell 103 and 7-bit ASCII coding
  • European Deaf Telephone (EDT), 110 bit/s half duplex V.21, and 7-bit codes
  • Minitel, V.23 modems, and 7-bit codes
  • Modems and 7-bit codes
  • Dual Tone MultiFrequency (DTMF), using 2 – 3 digit character codes

ITU recommendation V.18 codifies how all of these devices work and how to adaptively connect to all of them. ITU recommendation V.25ter contains AT commands for control of V.18 features in a modem.

It is recommended to include Text Telephone capability, for the type commonly used in the country of sale and use (for example, Baudot in the U.S., Minitel in France). ASCII (Bell 103), V.21, and V.23 modem capability are common in modems. Voice modems (IS-101 type) commonly contain the ability to do DTMF send and receive. Baudot and EDT can be implemented in software using voice modems and simple software signal processing. However, because the adaptive connection phase is difficult to implement in software, even on a voice modem, it is best to implement V.18 in the modem itself and expose that functionality to the PC using the V.25ter commands.


Voice and Adaptive Connection Technologies for Modems

This section provides requirements and recommendations related to voice, voice/data integration, and adaptive connection.

If any feature is implemented in a modem, if must meet the standards for the feature as defined here to qualify for the "Designed for Microsoft Windows" logo.

7. TIA-695 (AT+V); Speakerphone, if voice modem capabilities

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Required

Voice features in a modem are valuable for telephone answering functions, supporting applications such as MS-Phone. The current version of the Universal Modem Driver in Windows 95 (Unimodem/V) supports voice modems. The Unimodem driver in Windows NT 4.0 does not support voice; it is planned that future versions will.

The two significant components of the voice command sets are:

  • Voice recording and playback features, with associated commands for formatting and volume control, and so on.
  • Call progress and call control signaling.

Note By late 1996, IS-101 will be superseded by TIA-695, the complete standard. Manufacturers are encouraged to migrate their products to TIA-695.

The industry standard command set for voice modems is the AT+V command set, currently specified in TIA-695. This consists of Hayes AT (ATTENTION) prefixed commands, +V (Voice) prefixed commands, and DLE-shielded in-band commands. Most voice modems currently are compliant with either AT+V or an equivalent (for example, Rockwell AT#V). Microsoft requires the command set for new modems to follow the syntax and functions of AT+V.

Some of the features discussed are based upon Bellcore Custom Local Area Signaling Services (CLASS) that are widely offered by local exchange carriers in North America. These services convey to the customer's premise equipment (CPE) information made available through interoffice signaling between CO switches. For more details about CLASS features, see the related Bellcore documents listed later in this section.

Speakerphones can be either half-duplex or full-duplex. In a full-duplex speakerphone, avoid using user-initiated training sequences for either electrical or acoustical echo canceller taps. Also, avoid using long downloads or uploads of data for loading of speakerphone filter taps. Speakerphone control should be achieved by way of AT commands that provide the ability to enable and disable the speakerphone and to adjust the output volume and input microphone level.

Unimodem supports the telephone line audio path using a Windows waveform driver. This architecture is described in the Microsoft Windows Programmer's Guide. The wave-in and wave-out devices connected to the phone line must support 8 kHz, monaural, 16-bit PCM format wave data. Additional waveform driver requirements are described in the MDK. The current implementation of Unimodem can support IMA ADPCM at three sample rates (8000 Hz, 7200 Hz, or 4800 Hz) and Rockwell ADPCM.

An alternative Unimodem implementation is acceptable if it achieves similar or better performance.

8. Voice-coding: real-time wave encoder/decoder

Recommended

This can be an ADPCM, such as IMA or Rockwell, or a device with a Windows waveform driver.

9. Adaptive connection support, V.25, V.8, and V.8bis call control signaling, with V.25ter Annex A modem commands

Recommended

V.25, V.8, and V.8bis call mode discrimination signaling, with V.25 call mode discrimination commands and responses, and V.8 or V.8bis call mode discrimination command set (V.25ter Annex A).

For PC 97, all modems must support V.34 modulation. V.34 in turn requires V.8 call control signaling. To support PC-controlled adaptive connection, modems must support V.25ter Annex A commands, so that the PC and modem driver can adaptively recognize and sort data calls from voice calls.

Further, to support videophone or voice/data integration, modems must support V.8bis call modality signaling, with the corresponding V.25ter Annex A commands.

Call Modality Discrimination issues arise when a telephone line expects calls of either voice, fax, or data modes. For example, this situation arises when data mode devices such as a fax machine or a data modem are attached to a line that also handles voice calls. VoiceView, fax, SVD, videophone, and data calls are examples of the potential for shared use on a voice line. Problems arise when the two ends of a call determine how the call will be handled; for example:

  • A data modem dials a voice-only number.
  • A voice caller calls a data-only line.
  • A multimode device answers or calls to communicate by either voice or data mode but cannot determine which mode is appropriate.

Examples of problems are the following:

  • Voice caller hangs up upon hearing "machine tones" even though voice mode is supported by an IVR application.
  • A call terminates abnormally because devices cannot agree on an appropriate connection modulation and protocol.

ITU V.25 defines calling and answering tones for fax and data calls. These are commonly used in faxes worldwide but not commonly used for data calls (although it is mandatory in some countries). It is recommended that data modems contain features to enable generation and detection of these signals, for affirmative detection of incoming fax and data calls. For standard AT commands and responses for these features, see TIA IS-101 and V.25ter Annex A.

ITU V.8 defines means for the calling or originating modem to communicate the selected call types to the answering or responding modem at the beginning of the call. V.8 Call Indication (CI) signal allows a calling modem to announce the desired call type to the answering modem, so the answering modem can do clean voice/data/fax switching. V.25ter Annex A commands allow the PC to enable CI on the calling side and to detect and respond to it with the appropriate application on the answering side. V.8 is required for all V.34 modems. Proprietary and standard AT commands are available for control of V.8 negotiation; see V.25ter Annex A.

Several vendors implement a market standard for DSVD (Digital Simultaneous Voice and Data). These devices use V.8 for call negotiation.

ITU V.8bis supports automatic determination of the appropriate mode of interoperating by means of an unobtrusive, brief, dual-tone mechanism to establish that both ends of a call support V.8bis. These can be used at the beginning of the call or at a later time. Such a brief DTMF burst can easily be dismissed by the voice caller as a remnant of network signaling, unlike a repetitive train of V.21 modulation that might be interpreted as "fax machine tones" when two data modems negotiate. The brevity and user-friendliness of the dual-tone mechanism addresses the first problem described above.

V.8bis call discrimination is required for ITU Simultaneous Voice/Data technologies such as the new V.70 suite, and including PSTN Videophones (H.324). Standard commands for PC control of V.8bis negotiation are defined in V.25ter Annex A (1996).

Modems that support IS-101 (predecessor to TIA-695) can also support automatic attendant applications that use a voice outgoing message to prompt callers to identify themselves (by speech recognition or DTMF) and specify the desired call type.

References:
Call Modality Discrimination (ITU/T V.8bis)

V.8bis combines Call Modality Discrimination, Terminal Selection, and Capability Exchange and Selection to provide automatic call termination on
a multimode line. V.8bis seeks to make these connections both temporally efficient as well as "listener friendly" to the voice mode caller.

ITU-T V.25ter or TIA-602

This lists the AT command set, with standard extensions for modem ID, local port control, modulation control, and so on. Annex A covers adaptive call control using V.25 calling tones, V.8 and V.8bis negotiations, and some fax signals.

TIA Standard TIA-695 (AT+V Modem)

TIA-695 is the ANSI/TIA/EIA standard for voice modems, entitled the "Facsimile Digital Interfaces—Voice Control Standard for Asynchronous DCE."

The standard includes a voice control-and-response interface definition, a collection of basic functions that allow the DTE to implement a call discrimination algorithm, and a control structure that includes data, fax, voice, and other future modes. This standard is currently the most complete statement of voice modem requirements. This standard defines the +V subcommands for the AT command set.

Eventually, TIA-695 will be partial basis for an ITU recommendation.

10. Support existing CPE, local telset, extension off-hook detection, and loop sensing, if voice modem capabilities present

Recommended

The following capabilities of the local telset attached to the modem should be supported:

  • Detection of hook-switch state of the local telset at all times
  • Ability to perform wave input and wave output to the local handset device
  • Detection of loop current reversal on the local loop (remote disconnect)
  • Detection of loop-voltage change (local extension on-/off-hook)

References:
Bellcore TR-NWT-000030

"Voiceband Data Transmission Interface Generic Requirements."

Bellcore SR-TSV-002476

"CPE Compatibility Considerations for the Voiceband Data Transmission Interface."

Bellcore TR-NWT-001401

"Visual Message Waiting Indicator Generic Requirements."

11. Simultaneous voice/data integration capabilities

Recommended

The following technologies can be used to support simultaneous voice/data:

  • Analog Simultaneous Voice and Data (ASVD) —that is, ITU V.61, proposed "V.34Q," VoiceSpan, MediaLink.
  • Digital Simultaneous Voice and Data (DSVD) —that is, MultiTech PCS, market standard DSVD, ITU V.70 suite, ITU H.324 (Video Telephony).
  • Alternating Voice and Data (AVD) — that is, VoiceView (discussed in the following optional item).

In recent years, there has been a profusion of incompatible choices for Voice Data technology. In the short term, the confusion over multiple DSVD technologies has opened the door for the simpler but useful ASVD techniques. ("V.34Q" standardization should be completed in ITU.) However, the recent completion of V.70 and H.324 should converge the market. Future versions of Windows will attempt to allow IHVs and ISVs to accommodate all of them, so that manufacturers and customers can choose based on their needs.

Microsoft is an active member of the International Multimedia Telecommunications Consortium (IMTC). Currently, the IMTC appears to be backing ITU H.324 for voice/data integration, as a substrate for ITU T.120 conferencing. Interested parties are invited to join and participate in the work of the IMTC, and in related ITU study groups.

It is recommended for PC 97 to include the new ITU V.80 recommendation in the modem control function. (See the recommendation for Synchronous Access Mode for data modems earlier in this chapter). V.80 allows complex modem functions (that is, V.42, the V.75 DSVD multiplexor, the H.223 videophone multiplexor) to be implemented in Windows drivers. The advantages are that the resulting system is more powerful and more flexible, data processing is uploaded to the PC where it belongs, and the modems can remain cost competitive.

V.8bis is required for standard DSVD (V.70) or video telephony (H.324) calls.
It allows mutual capabilities exchange between PCs during a voice call, and transition from pure voice to voice/data/video.

V.25ter Annex A commands allows the PC to initiate V.8bis negotiation with the remote PC/terminal, respond to V.8bis signals from the remote PC, and then launch the appropriate application.

Note PC manufacturers who supply POTS-based video conferencing solutions must supply H.324 – compatible modems with their PC systems. ISDN-based video conferencing solutions should be H-320-compatible.

12. VoiceView as alternating voice/data integration capabilities

Optional

VoiceView is a useful but obsolete means for voice/data integration. It is not recommended for new designs.

A voice modem might be able to switch a call from voice to data and back to voice using the VoiceView AVD protocol. Modem firmware and hardware features, such as detecting VoiceView-specific tones and muting the earpiece during data transfer, are necessary for optimal VoiceView AVD modem design.

To facilitate automatic switching from AT+V mode (service class 8) to other service classes, a modem should allow detection of VoiceView start sequences while in AT+V mode. The modem should monitor the line for VoiceView events in addition to the normal AT+V monitoring.

When a VoiceView event is detected on the phone line, the modem mutes the local handset and issues a <DLE>-extended packet to the application (usually the TSP). The extended packet corresponds to one of eight possible VoiceView event responses. After a VoiceView data mode start sequence, the modem should start the data pump to receive VoiceView data and wait for the application to request a switch to VoiceView data mode, as described in the VoiceView Protocol Specification.

For all other event types, the modem simply completes the necessary responses and acknowledgments, unmutes the local handset, and resumes normal AT+V operation.

Reference:
Alternating Voice or Data (VoiceView) Modem, FCLASS=80;
VoiceView Tone Detection by Voice Modems, FCLASS=8

Details of the VoiceView alternating voice/data protocol are available from Radish Communications, Boulder, Colorado, USA; (303) 443-2237.


CLASS Services and Other Features for Modems

This section provides requirements and recommendations related to CLASS services.

If any feature is implemented in a modem, if must meet the standards for the feature as defined here to qualify for the "Designed for Microsoft Windows" logo.

13. Distinctive ringing class service

Recommended

This feature is recommended for implementation where applicable. Distinctive ringing assigns multiple phone numbers to a single line for which each number has its own special ring pattern. IS-101 defines a method for reporting the ringing cadence.

Reference:
Bellcore TR-TSY-000219

CLASS Feature: Distinctive Ringing/Call Waiting FSD 01-01-1110, or see ANSI T1.401.02-1995.

14. Caller ID service

Recommended

This feature is recommended for implementation where applicable. Caller ID is generally available only in North America and is not legal in some countries. This feature will never become a design requirement.

In the U.S. implementation, Calling Number/Name ID conveys the number from which a call originates. In addition, the directory name, date, and time of day is transmitted.

If reliable call-waiting subscriber alerting tone technology is available, the identity of a second caller can be conveyed as described in the Bellcore "Calling Identity Delivery on Call Waiting" document listed below. This gives the customer the same Caller ID capabilities on both incoming calls when call waiting is available. Caller ID might not be implemented in the same fashion in all jurisdictions—that is, an implementation can employ DTMF signaling not preceded by a ring.

A modem should support Caller ID information as a text string reported between rings, as defined in TIA-695 for use in modem states other than +FCLASS=8. If voice features are also supported in the modem, then the appropriate TIA-695 DLE sequences must also be supported.

References:
Bellcore TR-NWT-000031

CLASS Feature: Calling Number Delivery FSD 01-02-1051.

Bellcore TR-NWT-001188

CLASS Feature: Calling Name Delivery Generic Requirements FSD 01-02-1070.

Bellcore TR-NWT-000575

CLASS Feature: Calling Identity Delivery on Call Waiting FSD 01-02-1090.

Bellcore TR-TSY-000571

CLASS Feature: Call Waiting FSD 01-02-1201.

Bellcore TR-NWT-000575

CLASS Feature: Calling Identity Delivery on Call Waiting FSD 01-02-1090.

Bellcore TR-NWT-00416

CLASS Feature: Call Waiting Deluxe FSD 01-02-1215.

15. Dial string modifiers for DTE-DCE commands

Recommended

In addition to the dial string characters described in V.25ter or TIA-602, use of the dollar-sign character ($) is recommended to wait for the calling-card prompt tone (so-called "bong tone"). Bellcore's BOC Notes on the Network (SR-TSV-002275, Issue 2, April 1994, Section 5 Signaling, page 6 – 218) describes this tone for North American LECs. Some European administrations are also implementing this capability.

16. In-band Voice Mode (AT+V) responses for DTE-DCE commands

Recommended

This feature is recommended for implementation where applicable. As a general rule, modem events should be reported in all configurations of speakerphone and handset. In-band responses are also known as events, as described in the related TIA-695 documents. Alternatives to the serial asynchronous connection between DCE and DTE exist. The use of in-band responses with a separate voice data path is optional. The MDK describes waveform driver development for such an alternative architecture.

17. Compound Voice Mode (AT+V) responses for DTE-DCE commands

Recommended

This feature is recommended for implementation where applicable. Compound responses are known as Complex Event Detection Reports and are described in the related TIA-695 documents.

18. Telephone wave device compression method selection

Recommended

This feature is recommended for implementation where applicable. TIA-695 section 10.2.8, "Compression Method Selection," describes the +VSM= command and lists Compression Method identifier numerics and strings. The association between the WaveFormat registry key and the +VSM= command is described in the MDK.

19. Cellular phone support

Recommended

This feature is recommended for implementation where applicable. Cellular telephone systems are widely deployed around the industrialized world and are now being deployed everywhere else. In North America, analog cellular systems (TIA-553) are currently predominant, although two types of digital cellular systems will also be deployed: Code Division Multiplexed Access (CDMA, TIA IS-95) and Time Division Multiplexed Access (TDMA, IS-136). In Europe and the rest of the world, the GSM digital cellular system is widely deployed.

In both analog and digital systems, there have been problems with implementing data and facsimile communications. For analog cellular, the problem is that the noise, fade, and signal drop-out problems tolerated by human speakers will cripple ordinary data modems. In the case of digital cellular, the problem is that the voice coding algorithms used cannot pass modem carriers intact at all.

In North America, standards have been developed for the modem-to-modem protocols to survive analog cellular impairments, such as Microcom's MNP 10 and AT&T Enhanced Cellular Protocol (ECP). These are helpful and recommended where applicable. Also, modern modem technologies such as V.34 are better able to get some useful data bandwidth on analog cellular connections than V.32bis or V.22bis modems.

There is also a new standard extended command set, defined in TIA-678, for general wireless modem control, with specific extensions for supporting analog cellular connections and analog cellular phones. (Notice that TIA-678 is technically identical to PCCA STD-101 and Annexes A, F, and I.)

For all three digital cellular systems, the system design has been extended to offer data, fax, voice, and short messaging (SMS) services to mobile users. In all cases, a modem pool is added to the ground stations, where connection is made to the Public Switched Telephone Network (PSTN). Access to the logical serial ports of these modems is made using the digital error-controlled radio link to the equipped mobile phone and is exposed on a serial port or associated PC Card.

The AT command sets for these digital cellular phone systems are contained in the following standards.

Standard | Command set
GSM 7.07 | GSM system: data, fax, voice
GSM 7.05 | GSM Short Messaging Services
TIA IS-99 | North American CDMA: data and fax
TIA IS-135 | North American TDMA: data and fax

20. Support for blacklisted and delayed number clearing

Recommended

The modem should clear its blacklisted and delayed number tables if the associated handset goes off hook.

During certain international PTT certification processes, modems must support the blacklisted and delayed numbers feature. That means that when the modem fails to dial a specific number for a certain number of times, the dialed number is stored in an internal list. Any subsequent automated dialing operation to this number is then either delayed for a time (delayed) or might be forbidden until some form of manual intervention occurs (blacklisted). The international certification processes specify that manual intervention using an external device is required in order to clear these numbers.


PC 97 Design for Modems

This section summarizes requirements related to the design initiatives for PC 97 in Part 1 of this guide.


Plug and Play and Bus Design for Modems

The items in this section are requirements for Plug and Play capabilities.

21. Plug and Play device identifier

Required

  • For a non-bus-specific system board device, there must be a device-specific identifier.
  • Each bus-specific device must provide a Plug and Play device identifier in the manner required for the bus it uses, as defined in Part 3 of this guide. For example, a PCI device must comply with PCI v. 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide.

Note Implement either a bus Plug and Play ID or a COM port Plug and Play ID, but not both.

22. Automatic resource assignment and dynamic disable capabilities

Required

The system must be capable of automatically assigning, disabling, and relocating the resources used by this device when necessary, using the method required for the related bus class. Changing or adding this device to the system must not require changing jumpers or switches on either the adapter or the system board. In the event of an irreconcilable conflict with other devices on the system, the system must be able to disable the device to prevent the system from stalling.

23. Minimum resource requirements for ISA and legacy devices

Required

As for all PC 97 devices, unique 16-bit I/O address decoding is required. These are the required resource settings for ISA and legacy devices:

  • 4 unique I/O locations

    Recommended: 7 I/O locations

  • 2 unique IRQ signals

    Recommended: 7 IRQ signals

  • 3 DMA channel selections, if DMA is used

Notice that, as for all devices, IRQ sharing is required if the minimum resource requirements cannot be met.

24. PCI v. 2.1 or higher, if PCI is used

Required

This device must comply with the PCI v. 2.1 specification if PCI is used as the bus connection for the modem. This ensures that all Plug and Play requirements are met and that Microsoft drivers support this device.

25. USB communications device class specification, if USB is used

Required

This device must comply with the Universal Serial Bus Specification (v. 1.0 or higher) and the related USB device class specification. This ensures that all Plug and Play requirements are met and that Microsoft drivers support this device.

26. Meets all requirements for parallel peripherals, if LPT port is used

Required

This requirement means the modem is enumerated by the parallel port enumerator to ensure that the device is compatible with various parallel transfer modes. This includes standard, bidirectional mode, ECP, and EPP modes. For information about requirements for parallel port peripherals, see the "Serial, Parallel, and Wireless Support" chapter.


Power Management for Modems

This section summarizes the specific power management requirements for modems. See also the specific power management interface requirements for the bus (PC Card, PCI, IEEE 1394, or USB) as defined in Part 3 of this guide.

27. Compliance with "Device Class Power Management Reference Specification"

Required

The "Device Class Power Management Reference Specification" for the Communication Device Class was developed with device manufacturers. This specification provides definitions of the OnNow device power states (D0 – D3) for these devices, including modems. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class. Power states D0 and D3 are required. Other power states are recommended.

28. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Required

For PC 97, a required feature for modems is the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for communications devices.


Device Drivers and Installation for Modems

This section summarizes requirements for device drivers for modems. The items in this section are requirements for all PC 97 systems.

29. Driver supports Unimodem

Required

The device driver must include Unimodem support.

30. Device driver and installation meet Windows and Windows NT standards

Required

The standard requirements for device drivers and installation include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry.
  • The correct minidriver, VxD, or any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations.
  • Driver installation and removal use Windows-based methods as defined in the Windows 95 and Windows NT DDKs and the Modem Developers Kit.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.

31. Applications provided with device meet Windows standards

Required

Any Windows-based applications provided with the device, such as fax utilities, must meet Microsoft requirements for software compatibility as indicated by the "Designed for Microsoft Windows" logo.


References for Modems

This section lists some of the publications, services, and tools available to help build hardware optimized to work with Windows operating systems.

Bellcore Technical References

Bellcore
U.S. and Canada: (800) 521-2673
Outside North America: (908) 699-5800

ITU, ANSI, or TIA communications standards

ITU Sales
Phone: (41) (22) 730-6141
Fax: (41) (22) 730-5194
E-mail: sales@itu.ch

Global Engineering Documents
Phone (U.S. and Canada): (800) 854-7179
Fax (outside North America): (303) 843-9880

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm

Windows 95 Modem Developers Kit (MDK)

ftp://ftp.microsoft.com/developr/drg/modem/modemdev.exe

Windows 95 and Windows NT Driver Developers Kit (DDK)

Microsoft Developers Network (MSDN) Professional membership

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm


Checklist for Modems

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Modems

1. Modem device provided with PC system

Recommended Required if no network adapter Required; voice/data recommended


Modem Basic Features

2. Modem command set: TIA-602, "Hayes compatible"

Required

3. Data modem: 28.8 Kbps (V.34-1994) with V.42 and V.42bis protocol

Required

4. Synchronous access for data modems: V.80 or similar technique

Recommended

5. Fax modem: 14.4 Kbps (V.17) with Class 1 (TIA-578-A) command set

Required

6. Telephone Device for the Deaf (TDD): V.18 with V.25ter command

Recommended

Voice and Adaptive Connection Technologies for Modems

7. TIA-695 (AT+V); Speakerphone, if voice modem capabilities

Recommended Recommended Required

8. Voice-coding: real-time wave encoder/decoder

Recommended

9. Adaptive connection support, V.25, V.8, and V.8bis call control signaling, with V.25ter Annex A modem commands

Recommended

10. Support existing CPE, local telset, extension off-hook detection, and loop sensing, if voice modem capabilities present

Recommended

11. Simultaneous voice/data integration capabilities

Recommended

12. VoiceView as alternating voice/data integration capabilities

Optional

CLASS Services and Other Features for Modems

13. Distinctive ringing class service

Recommended

14. Caller ID service

Recommended

15. Dial string modifiers for DTE-DCE commands

Recommended

16. In-band Voice Mode (AT+V) responses for DTE-DCE commands

Recommended

17. Compound Voice Mode (AT+V) responses for DTE-DCE commands

Recommended

18. Telephone wave device compression method selection

Recommended

19. Cellular phone support

Recommended

20. Support for blacklisted and delayed number clearing

Recommended


PC 97 Design for Modems

Plug and Play and Bus Design for Modems

21. Plug and Play device identifier

Required

22. Automatic resource assignment and dynamic disable capabilities

Required

23. Minimum resource requirements for ISA and legacy devices

Required

24. PCI v. 2.1 or higher, if PCI is used

Required

25. USB communications device class specification, if USB is used

Required

26. Meets all requirements for parallel peripherals, if LPT port is used

Required

Power Management for Modems

27. Compliance with "Device Class Power Management Reference Specification"

Required

28. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Required

Device Drivers and Installation for Modems

29. Driver supports Unimodem

Required

30. Device driver and installation meet Windows and Windows NT standards

Required

31. Applications provided with device meet Windows standards

Required


Chapter 20 Network Communications

This chapter presents the requirements and recommendations for network adapters and related technologies under the Microsoft Windows family of operating systems.


Overview for Network Communications

This section presents the key PC 97 design issues for network communications devices under Microsoft Windows.

Under Microsoft Windows, the seamless integration of network software components should be supplemented by device support for Plug and Play and NDIS 4.0 capabilities, so that the user has to supply a minimal amount of information to achieve optimal configuration.

For PC 97, all network communications devices are based on the same NDIS 4.0 requirements. These are the key PC 97 design issues for network communications:

  • Complete Plug and Play capabilities, with a supporting NDIS 4.0 miniport driver.
  • Automatic cable sense and transceiver auto-detection capabilities, plus support for power management capabilities under the OnNow design initiative.

Tips for Selecting High-Performance Network Adapters. For PC manufacturers who want to select high-performance components, these are design features to look for in network adapters:

  • Adapter supports bus mastering, especially for use with Pentium Pro-class processors.
  • PCI adapter properly supports higher-level PCI commands for intelligent data transfer.
  • Drivers tuned for 32-bit performance.


System Requirements for Network Communications

This section summarizes both the basic hardware design features for network communications devices and the specific features for PC 97.

1. Network adapter included in PC system

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Required if no modem | Recommended

It is recognized that OEMs supply PC systems to corporations for networking purposes in situations where the customer will insert network adapters at the end-user site. If the device is present in the PC system, it must meet the minimum requirements for network adapters defined in this chapter.

Note For Workstation PC 97, the network adapter must not use the ISA bus.

2. Internal or external ISDN devices

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Recommended | Recommended | Recommended

If the device is present in the system, it must meet the minimum requirements for ISDN devices defined in this chapter.

3. Cable modem built into PC

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Optional | Optional | Optional

Cable modems are not required features for any PC 97 system. If the device is present in the PC system, it must meet the minimum requirements for cable modems defined in this chapter.

4. ATM adapter built into PC

Basic PC 97 | Workstation PC 97 | Entertainment PC 97
Optional | Optional | Optional

Asynchronous transfer mode (ATM) adapters are not required features for any PC 97 system. If the device is present in the PC system, it must meet the minimum requirements for ATM adapters defined in this chapter.


Network Device Requirements

This section summarizes the requirements for network adapters for PC 97.


Network Adapter Basic Features

This section defines requirements for basic hardware features.

5. Support NDIS 4.0 using a miniport driver

Required

For PC 97, the driver must be an NDIS 4.0 miniport driver that is compatible with Windows NT 4.0 and Windows 95. If the device is switched WAN card (for example, ISDN, X.25, or S56), it must have an NDIS 4.0 NDIS WAN miniport driver which has a TAPI service provider compatible with Win32 TAPI applications. It must support Windows remote access or other WAN services over WAN media.

All enhancements to NDIS can be only used by miniport drivers, including all the features added in NDIS 4.0. All new media are being supported only in the miniport model, including ATM, WAN (ISDN, X.25, and so on), wireless WAN, IrDA, cable modem, ADSL, and so on.

This support also provides for dynamically starting and stopping the network adapter, and includes support for cable sense (see the following requirement). Because the operating system is performing a larger portion of the functionality in the miniport driver model, NDIS is safer, more efficient and binary compatible across operating systems than with other driver models. Writing miniport drivers is easier and requires less time and resources than drivers created under other driver models.

For information about NDIS and required driver support for the network adapter, see the Microsoft Windows NT 4.0 DDK and the Microsoft Windows 95 Device Driver Reference available by way of MSDN Professional membership.

6. Automatically sense presence of link or carrier to the network

Required

The network adapter must be capable of determining whether it is connected to a functional network. If the adapter is on an expansion card not used as a boot device, the presence of the cable can be determined by device drivers. If a cable is not attached, the miniport driver must provide appropriate NDIS status indication, using support for cable sense in NDIS 4.0. For information about NDIS Status codes and indication mechanism, see the Microsoft Windows NT 4.0 DDK.

No time durations are specified for the required detection or status indication.

7. Automatically sense transceiver type (TP, AUI, BNC)

Required

Network adapters that support multiple transceivers must be capable of automatically detecting which transceiver is connected to the network and then use that transceiver automatically. In all cases, the user must not be required to set jumpers or manually enter information to inform the operating system of the transceiver type.

8. Support quad-word buffer alignment or better for receive and support byte buffer alignment for send

Required

Recommended: byte alignment. All allocated memory will be quad-word alignment so the receive buffers must be quad-word aligned or better (can be byte or word aligned). For the send buffer, it must be capable of handling byte-aligned buffers. The network adapter must have minimal buffer alignment restrictions. This refers to the allowed offset addresses (boundaries) where packets can begin and end. Byte alignment is recommended, because it imposes fewer limitations on overlying software components.

9. Adapter communicates with driver across any bridge

Required

If the adapter uses a bridge, all communications must be free of errors across any bridge such as a PCI bridge adapter.


ISDN Basic Features

This section summarizes the design features for ISDN devices. ISDN is a new area for requirements. For PC 97, ISDN is a recommended but not required device for high-speed connections. If it is implemented, ISDN in a PC 97 system must meet the requirements defined in this chapter. For basic requirements for Plug and Play, power management, and driver support, see the "PC 97 Design for Network Communications" section later in this chapter.

An internal ISDN adapter plugs into the internal PC bus and appears to the operating system as a network adapter. An external ISDN adapter connects to an asynchronous port such as a serial port or USB and appears as a COM device to the operating system.

10. Support PC 97 requirements for network adapters

Required

The following requirements must be met, as defined in the "Network Adapter Basic Features" section earlier in this chapter:

  • Support NDIS 4.0 using a miniport driver
  • Automatically sense whether a cable is connected
  • Support quad-word buffer alignment or better
  • Adapter communicates with driver across any bridge

11. Synchronous HDLC framing for internal ISDN device

Required

HDLC framing is a standard for sending synchronous data.

12. AT command set for external ISDN device: TIA-602

Required

TIA-602 is a subset of ITU V.25ter. This can be implemented in the device or in the communications driver.

13. Async-to-sync conversion for external ISDN device

Required

Because ISDN is a synchronous service and an external ISDN device connects to an asynchronous port on the PC, the external device must provide some means of converting asynchronous data to synchronous data.

14. Built-in NT-1

Recommended

An NT-1 (network terminator) splits the duplexed transmit and receive signals from the ISDN line into separate transmit and receive components. An ISDN device with a built-in NT-1 can connect directly to the ISDN line. However, doing so prevents other devices from being attached to the ISDN line (only one NT-1 can be connected to an ISDN line).

For this recommendation, it is recognized the NT-1 applies only for the United States.

15. Multilink PPP (RFC 1717) for external ISDN device

Recommended

Multilink PPP combines several ISDN B channels to increase the bandwidth of PPP links.

This requirement is for external devices only. NDIS WAN miniport drivers for internal devices benefit from the built-in multilink support provided by the remote access services of the operating system and do not need to provide multilink PPP support.

16. External ISDN device uses high-speed port

Recommended

Because of speed limitations inherent in the COM ports on the PC, the connection for external ISDN devices should use a high-speed connection such as USB.

17. NDIS WAN miniport for internal ISDN device

Required

The device must have an NDIS WAN miniport driver to support Windows remote access over ISDN. For information, see the Windows NT 4.0 DDK.

18. Binary compatibility between Windows 95 and Windows NT for ISDN drivers

Recommended

Drivers should not make calls to specific functions for either Windows 95 or Windows NT.


Cable Modem Basic Features

Cable modems are neither required nor recommended for PC 97, but if a cable modem is implemented in a PC 97 system, it must meet the requirements defined in this section. For basic requirements for Plug and Play, power management, and driver requirements, see the "PC 97 Design for Network Communications" section later in this chapter.

Cable modems connected to a PC are one component in a system that cable TV operators use to deliver High Speed Cable Data Services (HSCDS) to cable TV customers. HSCDS provides two-way services (data flows both "downstream" from the cable operator's head end and "upstream" from the customer's PC).

Ideally, two-way HSCDS is delivered over 450-MHz and 550-MHz hybrid fiber-coax (HFC) cable TV distribution networks. Most of the current cable TV distribution network in the U.S. is 300-MHz, 350-MHz, and 400-MHz coax branch and tree networks.

In 1996, HSCDS delivery has primarily been confined to trial projects. In these trials, the cable modems used on customer premises are typically external to the PC with their own power supply. These cable modems are essentially IP routers. The cable modem's upstream connection is either a standard "F" coax interface or an ATM interface. The cable modem connection to the PC uses a 10BaseT interface (RJ45) to connect a twisted pair to a standard Ethernet network adapter.

For the next several years, it is expected that external cable modems will be included as part of the HSCDS service by the cable operator, much like set top boxes. In light of that, along with the absence of standards for cable modems, few PC vendors are expected to bundle cable modem hardware with their systems.

PC platform vendors can build PCs that are capable of using external cable modems by including a standard Ethernet network adapter in their PC systems. The PC platform should also have Microsoft TCP/IP software pre-installed.

HSCDS upstream data flow can be implemented on the predominant 300-MHz, 350-MHz, and 400-MHz coax branch and tree cable TV distribution networks by using telephone circuits for the upstream channel. This is a design alternative used today to accomplish HSCDS field trails with existing cable TV networks until more HFC networks are built.

There are a great number of design issues for cable operators as they upgrade their cable TV distribution networks to HFC and begin to deliver HSCDS. Even operators who have existing HFC networks must add equipment to that network in order to begin offering HSDCS. The speeds at which cable TV operators resolve these issues will determine the requirements for cable modems in homes and businesses in two years. Although HSDCS is primarily only in trials today, a majority of the cable operators in the U.S. are working on business plans for delivering HSCDS within the next two years.

PC platform makers must track the rate at which cable TV operators are resolving these issues and what are the best methods. The key design issues for cable modems for PC platform makers are cost, standards, and the evolution of cable modems from external to internal models.

Some cable modem vendors plan to implement the new IEEE 802.14 protocol when it becomes available. It should be well suited to the distances, data rates, and physical plant scenarios for HSCDS on cable TV distribution networks.

For basic requirements for Plug and Play, power management, and driver support, see the "PC 97 Design for Network Communications" section later in this chapter.

19. Support PC 97 requirements for network adapters

Required

The following requirements must be met, as defined in the "Network Adapter Basic Features" section earlier in this chapter:

  • Support NDIS 4.0 using a miniport driver
  • Automatically sense whether a network cable is connected
  • Automatically sense transceiver type
  • Support quad-word buffer alignment or better
  • Adapter communicates with driver across any bridge

20. Provide platform support for external cable modems

Recommended

Plan to support external cable modems by supplying a low-cost Ethernet network adapter as part of a PC until a low-cost internal cable modem becomes available.

21. Provide Ethernet card solution

Recommended

PC platform makers providing a standard Ethernet card to connect to an external cable modem can contribute to a low-cost solution at the customer's end for the HSCDS service today.

Cable TV operators are extremely sensitive to the cost of every component it takes to deliver HSCDS over an HFC cable distribution network. For example, operators currently want the cable modem on the customer's site to cost no more than $500. Cable modem vendors are building devices that cost between $395 and $1495.

This cost sensitivity can be understood in the context of what it costs cable TV operators to upgrade their physical plant to deliver HSCDS. Estimates are that cable operators have spent over $500 per customer to build the existing physical plant. Upgrades of coax branch and tree networks to HFC are estimated to cost another $150 to $400 per household.

22. Participate in developing standards

Recommended

Microsoft encourages cable modem vendors to contact Microsoft about the devices they are designing. Microsoft wants to work with the cable TV industry in establishing standards for the use of cable modems in HSCDS delivery networks.


ATM Adapter Basic Features

ATM is a new area for requirements. Although ATM is not a required device for high speed connections, if it is implemented, it must meet these requirement.

For basic requirements for Plug and Play, power management, and driver support, see the "PC 97 Design for Network Communications" section later in this chapter. For more details about the following requirements, please refer to Section 3, "ATM Layer Specification," in ATM User-Network Interface Specification v. 3.1.

23. Support PC 97 requirements for network adapters

Required

The following requirements must be met, as defined in the "Network Adapter Basic Features" section earlier in this chapter:

  • Support NDIS 4.0 using a miniport driver
  • Automatically sense whether a network cable is connected
  • Support quad-word buffer alignment or better
  • Adapter communicates with driver across any bridge

24. Minimum VPI and VCI range

Required

On servers larger Virtual Path Identifier (VPI) and Virtual Channel Identifier (VCI) ranges are needed to support larger number of connections on servers.

System type | VPI | VCI
Client system | 0 | 0 – 255
Server system | 0 – 31 (or more) | 0 – 2048 (or more)

25. Traffic shaping

Required

Simpler Segmentation and Re-Assembly (SAR) chips support only "Peak Rate" traffic shaping — for example, you can only specify the peak rate per Virtual Channel (VC). In the ATM Forum's Traffic Management Specification, the Available Bit Rate (ABR) standard requires end-stations to be able to send and receive "Resource Management" (RM) cells used to control traffic in a bursty LAN-type environment. Eventually, both workstation and server PCs must be capable of supporting this.

System type | Method
Client system | Peak Rate
Server system | ABR from the ATM Forum's Traffic Management Specification

26. Operation and maintenance (OAM) support

Recommended for Client system; required for Server system (layers F1-F5)

This feature is needed for diagnostics.

27. Buffer chaining (Tx + Rx)

Recommended for Client system; required for Server system

This feature is needed for large packets.

28. External clocking

Required

Recommended method: ATM adapter supports both Internal and External (default) clocking. Usually, adapters can derive their transmit clocks from the switch's Sonet frames (external clocking). Internal clocking is useful for diagnostics (connect Tx to Rx, and so on).


PC 97 Design for Network Communications

This section summarizes requirements related to the design initiatives for PC 97 defined in Part 1 of this guide.


Plug and Play and Bus Design for Network Communications

The items in this section are requirements for Plug and Play capabilities.

29. Plug and Play device identifier

Required

  • For a system board device, there must be a Plug and Play device-specific ID.
  • The device must provide Plug and Play device identifiers in the manner required for the bus it uses, as defined in Part 3 of this guide. For example, a PCI device must comply with PCI v. 2.1 requirements and also provide a Subsystem ID and Subsystem Vendor ID, as defined in the "PCI" chapter in Part 3 of this guide.

30. Automatic resource assignment and dynamic disable capabilities

Required

The system must be capable of automatically assigning, disabling, and relocating the resources used by this device when necessary, using the method required for the related bus class. Changing or adding this device to the system must not require changing jumpers or switches on either the adapter or the system board. In the event of an irreconcilable conflict with other devices on the system, the system must be able to disable the device to prevent the system from stalling.

31. Minimum resource requirements for non-PCI devices

Required

As for all PC 97 devices, unique 16-bit I/O address decoding is required. These are the required resource settings for non-PCI devices:

  • 4 unique I/O locations
  • 4 unique IRQ signals
  • 3 unique memory address locations, if memory-mapped I/O is used
  • 3 DMA channel selections, if DMA is used

Notice that, as for all devices, IRQ sharing for ISA is required if the minimum resource requirements cannot be met.

32. Support multiple adapters

Required

For network communications devices, the Plug and Play identifiers and resource support must be sufficient to automatically support the addition of multiple network communications devices to the system. This is true for the same and differing types of network communications devices.

33. All resource settings can be changed in the user interface

Required

For Windows 95, for example, this means that all possible resource settings are available in Device Manager.


Power Management for Network Communications

This section summarizes the specific power management requirements for network communications devices.

34. Compliance with "Device Class Power Management Reference Specification"

Required

The "Device Class Power Management Reference Specification" for the Network Device Class provides definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class.

35. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

The "Device Class Power Management Reference Specification" for network devices includes a defined mechanism for programming the network adapter with one or more "wakeup packets" that, when received over the network, will generate a wakeup signal to the system using the wakeup signaling mechanism defined for the bus to which the adapter is connected. For PC 97, the ability to cause such a Wakeup event is an optional feature.


Device Drivers and Installation for Network Communications

This section summarizes requirements for device drivers for network communications devices, in addition to the requirements for using an NDIS 4.0 miniport driver, as defined in the "Network Adapter Basic Features" section earlier in this chapter.

36. Device driver and installation meet Windows and Windows NT standards

Required

The manufacturer does not need to supply a driver if a standard driver is provided with the operating system. If a manufacturer supplies drivers, requirements for device drivers and installation include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry. The driver must not use INI files for configuration settings.
  • The correct miniport driver or any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations. For manufacturer-provided files, the vendor must not be identified as Microsoft, and all other copyright and version information must be correct for the manufacturer.
  • Driver installation and removal use Windows-based methods as defined in the Windows 95 and Windows NT DDKs.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.

37. Windows NT-based detection DLL works correctly

Required

This ensures that the network communications devices is correctly identified during installation.

38. Driver supports promiscuous mode

Required

This ensures that the adapter can be used with Microsoft Network Monitor Agent. This requirement applies only to LAN media (non-switched).

39. Driver works correctly with Microsoft network clients and protocols

Required

This includes the 32-bit Microsoft client and NetWare-compatible clients provided with Windows, whether connected to a Windows NT-based server, a Novell NetWare 3.x or 4.x server, or a Windows-based peer server. For all cases, this includes connections using Microsoft TCP/IP, the IPX/SPX-compatible protocol, and NetBEUI.

40. NDIS miniport driver does not make operating system-specific kernel calls

Required

A miniport driver that follows the NDIS specification must not make operating system-specific calls. A correct driver makes calls only to the NDIS library. The NDIS library provides all the functions a driver needs or should use. This results in binary compatibility of the driver between Windows 95 and Windows NT.

NDIS conformance must be validated over a single network connection and multiple connections. For Windows NT, this must be validated on a multiprocessor system for any device that receives the "Designed for Microsoft Windows" logo.

41. Driver detects adapter availability for removable devices

Required

The device driver must sense the presence of the network device to determine whether the commands sent to and received from the network device are appropriate. This can be implemented using a known register address that can be queried. The device driver must inform the user if the network is not available.

42. Help file provided if special driver parameters are used

Required

This ensures that the user can change settings correctly. The user interface for displaying any driver-specific Help file must display the correct file. The Help file must contain relevant information.


References for Network Communications

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Windows NT 4.0 DDK and Windows 95 DDK

Microsoft Developer Network (MSDN)
Includes NDIS specifications, driver requirements, and Plug and Play support.

High-Speed Cable Data Service (HSCDS) RFP

An RFP for equipment and system integration capabilities that enables cable TV operators to offer High-Speed Cable Data Service (HSCDS) over the evolving hybrid fiber-coax (HFC) cable television infrastructure. Available from Cable Television Laboratories, Inc., 400 Centennial Parkway, Louisville, CO 80027.

ATM User-Network Interface Specification v. 3.1

Prentice Hall, 1995
ISBN 0-13-393828-X

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm


Checklist for Network Communications

Basic PC 97 Workstation PC 97 Entertainment PC 97


System Requirements for Network Communications

1. Network adapter included in PC system

Recommended Required if no modem Recommended

2. Internal or external ISDN devices

Recommended Recommended Recommended

3. Cable modem built into PC

Optional Optional Optional

4. ATM adapter built into PC

Optional Optional Optional


Network Device Requirements

Network Adapter Basic Features

5. Support NDIS 4.0 using a miniport driver

Required

6. Automatically sense presence of link or carrier to the network

Required

7. Automatically sense transceiver type (TP, AUI, BNC)

Required

8. Support quad-word buffer alignment or better for receive and support byte buffer alignment for send

Required

9. Adapter communicates with driver across any bridge

Required

ISDN Basic Features

10. Support PC 97 requirements for network adapters

Required

11. Synchronous HDLC framing for internal ISDN device

Required

12. AT command set for external ISDN device: TIA-602

Required

13. Async-to-sync conversion for external ISDN device

Required

14. Built-in NT-1

Recommended

15. Multilink PPP (RFC 1717) for external ISDN device

Recommended

16. External ISDN device uses high-speed port

Recommended

17. NDIS WAN miniport for internal ISDN device

Required

18. Binary compatibility between Windows 95 and Windows NT for ISDN drivers

Recommended

Cable Modem Basic Features

19. Support PC 97 requirements for network adapters

Required

20. Provide platform support for external cable modems

Recommended

21. Provide Ethernet card solution

Recommended

22. Participate in developing standards

Recommended

ATM Adapter Basic Features

23. Support PC 97 requirements for network adapters

Required

24. Minimum VPI and VCI range

Required

25. Traffic shaping

Required

26. Operation and maintenance (OAM) support

Recommended for Client system
Required for Server system (layers F1-F5)

27. Buffer chaining (Tx + Rx)

Recommended for Client system
Required for Server system

28. External clocking

Required


PC 97 Design for Network Communications

Plug and Play and Bus Design for Network Communications

29. Plug and Play device identifier

Required

30. Automatic resource assignment and dynamic disable capabilities

Required

31. Minimum resource requirements for non-PCI devices

Required

32. Support multiple adapters

Required

33. All resource settings can be changed in the user interface

Required

Power Management for Network Communications

34. Compliance with "Device Class Power Management Reference Specification"

Required

35. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

Device Drivers and Installation for Network Communications

36. Device driver and installation meet Windows and Windows NT standards

Required

37. Windows NT-based detection DLL works correctly

Required

38. Driver supports promiscuous mode

Required

39. Driver works correctly with Microsoft network clients and protocols

Required

40. NDIS miniport driver does not make operating system-specific kernel calls

Required

41. Driver detects adapter availability for removable devices

Required

42. Help file provided if special driver parameters are used

Required


Chapter 21 Printers

This chapter presents the requirements and recommendations for printers under the Microsoft Windows family of operating systems.


Overview for Printers

This section presents the key design issues for printers under Microsoft Windows. Printers and other devices attached to parallel ports should be capable of high-speed, bidirectional data transfers. The design criteria for parallel devices follow those for parallel ports described in the "Serial, Parallel, and Wireless Support" chapter.

The PC 97 requirements for printers and parallel ports seek to ensure the following:

  • Ensure maximum speed for transfer of parallel data between the system and the peripheral.
  • Ensure a true Plug and Play experience for users.


Basic Printer Features

This section summarizes the basic hardware requirements for printers for PC 97.


Basic Features for IEEE 1394 Printers

This section defines requirements for printers that use IEEE 1394.

1. Compliance with PC 97 requirements for IEEE 1394

Required

This bus is recommended in PC 97 for support of fast, high-density data transfer. For information about implementing IEEE 1394 for PC 97, see the "IEEE 1394" chapter in Part 3 of this guide.


Basic Features for USB Printers

This section defines requirements for printers that use USB.

2. Compliance with PC 97 requirements for USB devices

Recommended

This bus is required for PC 97 systems. It is recommended that USB printers conform to the USB Printer Class specification. For information about implementing USB for PC 97, see the "USB" chapter in Part 3 of this guide.


Basic Features for IEEE 1284 Printers

This section defines requirements for printers that use IEEE 1284.

3. Support compatibility mode, nibble mode, and ECP, compliant with IEEE 1284-I

Required

Parallel peripherals must implement nibble mode and compatibility mode. Nibble mode provides a means of transferring the identification string from the peripheral to the system. Compatibility mode provides backward compatibility with non–Plug and Play systems that do not support more advanced modes.

A parallel device complies with IEEE 1284 if it meets the required criteria documented in the IEEE 1284 specification, "Standard Signaling Method for a Bi-directional Parallel Peripheral Interface for Personal Computers." For a parallel device that connects to a PC 97 system, the minimum requirement is IEEE 1284 Level I compliance, which implements the compatibility and nibble modes, as specified in IEEE 1284 and defines the mechanical and electrical specifications of the peripheral.

A 1284-I– compliant peripheral uses the standard 1284-B connector. In all cases, ensure that there is enough space between the connectors and the surrounding enclosure to allow for a mating connector, the connector shell, and the latch assembly.

For more information about the electrical specifications for 1284-I– compliant peripherals, see the IEEE 1284 specification.

For more information about these mode requirements, see the following related requirements defined for parallel ports in the "Serial, Parallel, and Wireless Support" chapter:

  • .
  • .
  • .

4. IEEE 1284-II compliance

Recommended

Peripheral devices capable of handling the high-speed data rate should support the protocols of the IEEE 1284 ECP mode.

5. ECP printer works correctly when ECP mode is turned off

Required

This ensures that the user has correct printing support when ECP mode is not used.

6. Hardware supports error notification

Required

The following minimum errors must be reported individually by the hardware:

  • Out of Paper
  • Paper Jam
  • Load Other Paper Size


PC 97 Design for Printers

This section summarizes requirements related to the design initiatives for PC 97 in Part 1 of this guide.


Plug and Play for Printers

The items in this section are requirements for Plug and Play capabilities. For Plug and Play requirements related to the printer port on the PC, see the "Serial, Parallel, and Wireless Support" chapter in Part 4, or the related bus port requirements, such as IEEE 1394, in Part 3 of this guide.

7. Support Plug and Play for all supported buses

Required

Complete Plug and Play support must be implemented for all buses that the device supports. For information about the Plug and Play requirements, see the related bus-class definitions in Part 3 of this guide.

8. Compliance with requirements for IEEE 1284 peripherals

Required

These requirements include a Plug and Play device identifier as described in the IEEE 1284 specification. For more information, see the "Serial, Parallel, and Wireless Support" chapter in Part 4 of this guide.

Recommended: Support CompatibleID key in the device identification string.


Power Management for Print Components

This section summarizes the specific power management requirements for printers.

9. Compliance with "Device Class Power Management Reference Specification"

Required

The "Device Class Power Management Reference Specification" for printers provides definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class.

10. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" for printers is an optional feature.

11. Support USB or IEEE 1394 power management requirements

Required

Printers that support USB or IEEE 1394 must also support the power management requirements for those buses, as defined in Part 3 of this guide.


Device Drivers and Installation for Printers

This section summarizes requirements for device drivers for printers. The items in this section are requirements for all variations of PC 97.

12. Printer INF and installation meet Windows and Windows NT standards

Required

Each device requires a printer INF for both Windows 95 and Windows NT operating systems. The manufacturer does not need to supply a printer INF if a standard printer INF provided with the operating system can be used.

If the manufacturer provides an INF file, it must be complete and free of errors. This INF file must comply with the printer-specific extensions listed in the Windows 95 and Windows NT DKKs.

If the manufacturer supplies an INF or other files, the requirements for printer INFs and installation include the following:

  • All devices and files must pass testing by Microsoft WHQL.
  • All configuration settings are stored in registry.
  • The correct files specified in the device's INF must be installed in the correct locations.
  • Driver installation and removal use Windows-based methods as defined in the Windows 95 and Windows NT DDKs.
  • Files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.

For complete details about standard installation requirements for device drivers, see "Basic PC 97" in Part 2 of this guide.

13. Driver reports device capabilities correctly

Required

For Windows 95, this means that the driver correctly supports the DEVMODE structure as defined in the Windows 95 DDK.

14. Device driver supports error notification

Required

At a minimum, the device driver must support reporting to the user the errors reported by the hardware.

15. ICC color matching support

Required

The Image Color Matching (ICC) APIs and functionality for Windows 95 are described in the Windows 95 SDK and DDK on MSDN. Windows supports using color profiles that comply with the ICC Profile Format Specification. For information, see the International Color Consortium web site at http://www.color.org.

Minimum implementation of ICC color matching requires one or more ICC profiles to be installed. Providing a monitor color calibration utility is recommended for generating, editing, and installing ICC profiles.

Eastman Kodak, the supplier of the default color matching method for ICM in Windows 95, has a wide array of advanced color management technology and products including device profiles that can be used to optimize a system. For contact information, see the "References for Printers" section at the end of this chapter.

16. Port monitor software complies with DDK guidelines

Required

If the device includes bi-directional port monitor software that replaces the default Windows port monitor, this software must accurately report errors.

For information about implementing port monitor software, see the Windows 95 and Windows NT DDKs.

17. Driver supports "point and print" network installation

Required

This support means that the user is not required to provide disks or files when installing a new printer of the same type as another printer on the network.

18. Device available immediately after installation

Required

The user should not have to restart the system to be able to print immediately after installation is complete.

19. Accurate printable regions

Required

The printable regions that can be selected in the user interface must be accurately supported in the actual print output.

20. Driver for Windows NT supports required DDIs

Required

These are defined in the Windows NT 4.0 DDK. Win32-based printer drivers ensure that print commands from Windows NT-based applications are executed correctly on the specified printer or plotter. Because Win32 APIs are not hardware specific, it is the job of each printer driver to interpret the commands for its specific hardware.

21. Driver for Windows 95 supports required DDIs

Required

This requirement includes correct support for all features advertised for the device plus required support for Windows 95 features. For Windows 95, the DDIs that must be supported are listed in the "Printer Driver Overview" section of the Windows 95 DDK. This includes the following support, in addition to other support defined in the DDK:

  • TrueType glyph indices
  • Big fonts (those that require more than 64K to express)
  • Enhanced metafile (EMF) spooling
  • Bezier curve output
  • Services from the Windows 95 DIB engine

22. Device driver based on universal printer driver

Recommended

Microsoft provides a Universal Printer Driver (Unidriver), which is capable of carrying out requests (such as printing text, rendering bitmaps, or advancing a page) on most types of printers. To build a driver for a particular printer, a developer builds a minidriver, which accepts requests from GDI and then, in most cases, passes the request to the Unidriver along with information that describes the capabilities, commands, and resident fonts of the particular printer. For more information, see the Windows NT 4.0 and Windows 95 DDK.


References for Printers

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Windows 95 and Windows NT Device Driver Kits (DDK)

MSDN Professional membership.

International Color Consortium
ICC Profile Format Specification

http://www.color.org

Eastman Kodak

Attn. Color Management Group
164 Lexington Road
Billerica, MA 01821 USA
1-800-75COLOR

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm


Checklist for Printers


Basic Printer Features

Basic Features for IEEE 1394 Printers

1. Compliance with PC 97 requirements for IEEE 1394

Required

Basic Features for USB Printers

2. Compliance with PC 97 requirements for USB devices

Recommended

Basic Features for IEEE 1284 Printers

3. Support compatibility mode, nibble mode, and ECP, compliant with IEEE 1284-I

Required

4. IEEE 1284-II compliance

Recommended

5. ECP printer works correctly when ECP mode is turned off

Required

6. Hardware supports error notification

Required


PC 97 Design for Printers

Plug and Play for Printers

7. Support Plug and Play for all supported buses

Required

8. Compliance with requirements for IEEE 1284 peripherals

Required

Power Management for Print Components

9. Compliance with "Device Class Power Management Reference Specification"

Required

10. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

11. Support USB or IEEE 1394 power management requirements

Required

Device Drivers and Installation for Printers

12. Printer INF and installation meet Windows and Windows NT standards

Required

13. Driver reports device capabilities correctly

Required

14. Device driver supports error notification

Required

15. ICC color matching support

Required

16. Port monitor software complies with DDK guidelines

Required

17. Driver supports "point and print" network installation

Required

18. Device available immediately after installation

Required

19. Accurate printable regions

Required

20. Driver for Windows NT supports required DDIs

Required

21. Driver for Windows 95 supports required DDIs

Required

22. Device driver based on universal printer driver

Recommended


Chapter 22 Scanners and Digital Cameras

This chapter presents the requirements and recommendations for scanners and digital cameras under the Microsoft Windows family of operating systems.


Overview for Scanners and Digital Cameras

The PC 97 requirements for scanners and digital cameras seek to ensure a true Plug and Play experience for users:

  • Each device must comply with the PC 97 requirements for Plug and Play for the specific bus it uses.
  • Each device must supply a human-readable device ID in the manner required for the specific bus it uses.
  • Each device must comply with the PC 97 requirements for power management for that device type and for the specific bus it uses.


Scanners and Digital Cameras Basic Features

This section summarizes the basic hardware requirements for scanners and digital cameras for PC 97.

1. Identifiers for connectors for port and peripherals

Required

To ensure proper connection by the user between cable and connector, an icon or text identifier must be added to any external connector, using vendor designs or icons defined in Appendix A, "Icons." The icon can be molded into the plastic or printed (either stamped directly or affixed as a permanent sticker).

2. ICC color matching support

Required

The Image Color Matching APIs and functionality for Windows 95 are described in the Windows 95 SDK and DDK on MSDN. Windows supports using color profiles that comply with the ICC Profile Format Specification. For more information, see the International Color Consortium (ICC) web site at http://www.color.org.

Minimum implementation of ICC color matching requires one or more ICC profiles to be installed. Providing a monitor color calibration utility is recommended for generating, editing, and installing ICC profiles.

Eastman Kodak, the supplier of the default color matching method for ICM in Windows 95, has a wide array of advanced color management technology and products including device profiles that can be used to optimize a system. For contact information, see the "References for Scanners and Digital Cameras" section at the end of this chapter.


Scanner SCSI Requirements

This section summarizes requirements for scanners and digital cameras that use SCSI.

3. SCSI hardware complies with PC 97 SCSI requirements

Required

All SCSI hardware must comply with the requirements defined in the "SCSI" chapter in Part 3 of this guide. This ensures complete Plug and Play capabilities with SCSI hardware. For example, a user must be able to attach any SCSI peripheral on a system with SCSI support; the operating system should recognize it automatically, load and initialize the appropriate drivers, and then make the device available for use.

4. SCSI scanner must attach to any PC 97-compliant SCSI controller

Required

All SCSI scanners must be able to attach successfully to any SCSI controller that meets the PC 97 requirements defined in the "SCSI" chapter of this guide.


Scanner USB Requirements

This section summarizes requirements for scanners and digital cameras that use USB.

5. USB hardware complies with PC 97 USB requirements

Required

All USB hardware must comply with the requirements defined in the "USB" chapter in Part 3 of this guide, which includes the USB specifications for specific device types. This ensures complete Plug and Play capabilities with USB hardware and meets all the core and device requirements for USB. For example,
a user must be able to dynamically attach any USB peripheral to any USB connector; the operating system should recognize it automatically, load and initialize the appropriate drivers, and then make the device available for use.

6. USB scanners support string descriptors and comply with Image Class device requirements

Required

The device descriptor listed in section 9.6.1 of the USB core specification must have valid iManufacturer and iProduct string descriptor indexes. All USB scanners must support sections 9.4.3 and 9.6.5 of the USB core specifications.

All devices must comply with the USB Image Class device requirements.


Scanner IEEE 1394 Requirements

This section summarizes requirements for scanners and digital cameras that use an IEEE 1394 connection.

7. IEEE 1394 hardware complies with PC 97 requirements for 1394

Required

All IEEE 1394 hardware must comply with the requirements defined in the "IEEE 1394" chapter in Part 3 of this guide.


Scanner Serial Requirements

This section summarizes requirements for scanners and digital cameras that use the serial port.

8. Serial hardware complies with PC 97 requirements for serial hardware

Required

All serial hardware must comply with the requirements for serial devices defined in the "Serial, Parallel, and Wireless Support" chapter in this guide. This ensures that serial hardware has complete Plug and Play capabilities.

For example, a user must be able to attach any serial peripheral to any serial connector; the operating system should recognize it automatically, load and initialize the appropriate drivers, and then make the device available for use. Notice that this requirement includes complete support for the resource requirements for serial devices.

9. Serial scanners support ClassName and UserName PNP fields

Required

The COM device ID fields must fill in the ClassName field with "\SCANNER" and fill in the UserName field with a human-readable description of the device. For information, see the Plug and Play External COM Device Specification v. 1.0.


Scanner Parallel Requirements

This section summarizes requirements for scanners and digital cameras that use a parallel port.

10. Parallel hardware complies with PC 97 parallel requirements

Required

All parallel hardware must comply with the Plug and Play requirements for parallel ports, as defined in the "Serial, Parallel, and Wireless Support" chapter in this guide. This includes implementing the required support in the Plug and Play Parallel Port Devices Specification v. 1.0b.

These requirements and recommendations ensure that a parallel device has complete Plug and Play capabilities. For example, a user must be able to attach any parallel peripheral to any parallel connector; the operating system should recognize it automatically, load and initialize the appropriate drivers, and then make the device available for use.

Each parallel scanner or digital camera must have a Plug and Play device identifier for an IEEE 1284 peripheral. At a minimum, the device-ID string
must contain these keys: MANUFACTURER, MODEL, CLASS, and DESCRIPTION.

  • The CLASS key value for scanners is SCANNER.
  • The CLASS key value for digital cameras is DIGCAM.

A parallel device can also be designed to meet the recommendation to support
the COMPATIBLE key in the device identification string, as defined in the "Serial, Parallel, and Wireless Support" chapter.


PC 97 Design for Scanners and Digital Cameras

This section summarizes requirements related to the design initiatives for PC 97 in Part 1 of this guide.


Plug and Play for Scanners and Digital Cameras

The items in this section are requirements for Plug and Play capabilities. For Plug and Play requirements related to the parallel port on the PC, see the "Serial, Parallel, and Wireless Support" chapter in Part 3, or see the related bus port requirements in Part 3 of this guide.

11. Support Plug and Play for all supported buses

Required

Complete Plug and Play support must be implemented for all buses that the device supports. For information about the Plug and Play requirements, see the related bus-class definitions in Part 3 of this guide.

12. Plug and Play device identifier

Required

All devices for all buses must supply a human-readable device ID in the manner required for the bus it uses. The device ID requirements for each bus are defined in Part 3 of this guide, except the device ID requirements for devices that use the parallel port are defined in the IEEE 1284 specification, as summarized in the "Serial, Parallel, and Wireless Support" chapter in this guide.


Power Management for Scanners and Digital Cameras

This section summarizes the specific power management requirements for scanners and digital cameras.

13. Compliance with "Device Class Power Management Reference Specification"

Required

The "Device Class Power Management Reference Specification" for this Device Class provides definitions of the OnNow device power states (D0 – D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class.

14. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

For PC 97, the ability to cause a Wakeup event as defined in the "Device Class Power Management Reference Specification" is an optional feature.

15. Support power management requirements for bus

Required

The device must support the power management requirements for the bus it uses, as defined in Part 3 of this guide.


Device Driver and Installation for Scanners and Digital Cameras

This section summarizes the device driver requirements for scanners and digital cameras.

16. Device driver and installation meet Windows and Windows NT standards

Required

The manufacturer does not need to supply a driver if a standard driver provided with the operating system can be used. If the manufacturer supplies drivers, the requirements for installation include the following:

  • All devices and drivers must pass testing by Microsoft WHQL.
  • All configuration settings are stored in the registry.
  • The correct minidriver, VxD, or any other manufacturer-supplied files specified in the device's INF must be installed in the correct locations.
  • Driver installation and removal use Windows-based methods as defined in the Windows 95 and Windows NT DDKs.
  • Driver files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems, unless specifically agreed with Microsoft.
  • Only 32-bit protected-mode components are installed. No real-mode or 16-bit protected-mode components are provided in order to operate under Windows.
  • Driver supports Plug and Play IRPs (for WDM drivers) or messages (for VxDs).
  • If support using WDM drivers is provided in the operating system, the driver supplied by the manufacturer must be a WDM minidriver.

For complete details about standard installation requirements for drivers, see "Basic PC 97" in Part 2 of this guide.

17. Applications provided with device meet Windows standards

Required

Any Windows-based applications provided with the device must meet Microsoft requirements for software compatibility as indicated by the "Designed for Microsoft Windows" logo.


References for Scanners and Digital Cameras

This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.

Windows 95 and Windows NT Device Driver Kits (DDK)

MSDN Professional membership

Plug and Play specifications

http://www.microsoft.com/hwdev/pnpspecs.htm

Device Class Power Management Reference Specification

http://www.microsoft.com/hwdev/onnow.htm

International Color Consortium
ICC Profile Format Specification

http://www.color.org

Eastman Kodak

Attn. Color Management Group
164 Lexington Road
Billerica, MA 01821
1-800-75COLOR


Checklist for Scanners and Digital Cameras


Scanners and Digital Cameras Basic Features

1. Identifiers for connectors for port and peripherals

Required

2. ICC color matching support

Required

Scanner SCSI Requirements

3. SCSI hardware complies with PC 97 SCSI requirements

Required

4. SCSI scanner must attach to any PC 97-compliant SCSI controller

Required

Scanner USB Requirements

5. USB hardware complies with PC 97 USB requirements

Required

6. USB scanners support string descriptors and comply with Image Class device requirements

Required

Scanner IEEE 1394 Requirements

7. IEEE 1394 hardware complies with PC 97 requirements for 1394

Required

Scanner Serial Requirements

8. Serial hardware complies with PC 97 requirements for serial hardware

Required

9. Serial scanners support ClassName and UserName PNP fields

Required

Scanner Parallel Requirements

10. Parallel hardware complies with PC 97 parallel requirements

Required


PC 97 Design for Scanners and Digital Cameras

Plug and Play for Scanners and Digital Cameras

11. Support Plug and Play for all supported buses

Required

12. Plug and Play device identifier

Required

Power Management for Scanners and Digital Cameras

13. Compliance with "Device Class Power Management Reference Specification"

Required

14. Support Wakeup Events defined in "Device Class Power Management Reference Specification"

Optional

15. Support power management requirements for bus

Required

16. Device driver and installation meet Windows and Windows NT standards

Required

17. Applications provided with device meet Windows standards

Required


Appendix A Icons

This appendix presents a recommended set of standard icons that can be used for connectors on a personal computer. A set of icons must be added to any external connector on a PC 97 system. It is also recommended that the same icons also be added to any cable connectors that plug into the PC. (Icons are not required for peripherals or the peripheral end of the cable.)

Although no specific types of icons are required, you can base the icons either on existing vendor designs or on the icons shown in this appendix. Files that contain art for these icons, plus alternate icon designs from Hewlett-Packard, are available on http://www.microsoft.com/devdes/icons.htm.

For PC cases and cable plug housings, the icon can be molded into the plastic. Printed icons on labels that can be permanently affixed are also acceptable.

PC 97 does not make any specific requirements or recommendations for color coding connectors and other cable markings, but the PC designer is free to implement color coding to enhance the ease-of-use experience for users.

Connector Icons

Suggested icons Description

Monitor

Keyboard

Mouse

SCSI

Parallel /Printer

Gameport/Joystick

Monaural/Stereo In

Monaural/Stereo Out

Microphone

Serial Port

Serial Port 1

Serial Port 2

Network/Thicknet+Twisted

Headphone

Expansion Bus/Docking Station

Telephone Line

Telephone Set

USB


Appendix B Device Identifiers

This appendix lists CompatibleIDs for Vendor and Device IDs for Plug and Play.

NoteTo obtain a new Plug and Play vendor ID for a new device, please send e-mail to pnpid@microsoft.com.


Plug and Play Vendor and Device IDs

All non-BIOS enumerated devices must not use "PNP" in their Vendor and Device codes. Instead, the vendor must register with EISA and have a vendor code assigned (for example, CTL for Creative Labs). The "PNP" vendor code is reserved for Microsoft and can be used only when defining a device's CompatibleID after indicating the device's HardwareID in the Plug and Play header.

Use of CompatibleIDs is strongly recommended for devices that use inbox device drivers, such as a "Standard PC COM Port" (PNP0500) or "Sound Blaster 16-compatible Sound Device" (PNPB003).

The following example output from Isolate.exe of a Plug and Play header is provided for your reference.

Vendor ID:     XXXFFFF
Serial Number: 00000001
Checksum (reported): 0x5E
PNP Version:   1.0
Vendor Ver.:   10
Device Description: IDE Port
Device ID:  XXX0001
Doesn't Support I/O Range Checking
Vendor Defined Logical Device Control Registers:
None
Compatible Device ID: PNP0600
Device Description: IDE

Dependent Function 0
.
.
.
Dependent Function 1
.
.
.
End of Dependent Functions

When the user is installing devices that use this method, a dialog box appears at the beginning of the enumeration sequence to suggest use of the default driver that is provided with Windows 95. Windows 95 also provides the option for using a disk from the manufacturer, in case the user wants to choose a manufacturer-supplied driver.

For multifunction adapters, you should supply an INF file that chooses the appropriate drivers (including default drivers) for all the adapter's devices. This prevents additional dialog boxes from again requesting the default driver or a manufacturer's disk for the rest of the devices on the adapter.

When an INF file is used in this manner for default driver selection, it must link the HardwareID (XXX0000) to the appropriate compatible device driver from the Windows 95 distribution compact disc or installation disks. If this is not done, Windows 95 will continue to query the user for either the default driver or a new driver, thus defeating the purpose of using the INF file in this way.


Windows Generic Device IDs

Many devices, such as the interrupt controller or the keyboard controller, have no standard EISA ID. Also, a set of compatible devices, such as VGA and Super VGA, are not actually devices but define a compatibility hardware subset. Yet another set of IDs needs to be used to identify buses.

Microsoft has reserved an EISA prefix of "PNP" to identify various devices that do not have an existing EISA ID, and also uses "PNP" to define compatibility devices. The IDs are defined in the following tables.

Device ID Ranges

ID range | Category
PNP0xxx | System devices
PNP8xxx | Network adapters
PNPAxxx | SCSI, proprietary CD adapters
PNPBxxx | Sound, video capture, multimedia
PNPCxxx – Dxxx | Modems

The following obsolete device ID is provided only for compatibility with earlier device ID lists.

Device ID | Description
PNP0802 | Microsoft Sound System – compatible device (obsolete; use PNPB0xx instead)


Interrupt Controllers

Device ID | Description
PNP0000 | AT interrupt controller
PNP0001 | EISA interrupt controller
PNP0002 | Micro Channel interrupt controller
PNP0003 | APIC
PNP0004 | Cyrix SLiC MP interrupt controller


Timers

Device ID | Description
PNP0100 | AT timer
PNP0101 | EISA timer
PNP0102 | Micro Channel timer


DMA

Device ID | Description
PNP0200 | AT DMA controller
PNP0201 | EISA DMA controller
PNP0202 | Micro Channel DMA controller


Keyboards

Device ID | Description
PNP0300 | IBM PC/XT keyboard controller (83-key)
PNP0301 | IBM PC/AT keyboard controller (86-key)
PNP0302 | IBM PC/XT keyboard controller (84-key)
PNP0303 | IBM Enhanced (101/102-key, PS/2 mouse support)
PNP0304 | Olivetti keyboard (83-key)
PNP0305 | Olivetti keyboard (102-key)
PNP0306 | Olivetti keyboard (86-key)
PNP0307 | Microsoft Windows keyboard
PNP0308 | General Input Device Emulation Interface (GIDEI) legacy
PNP0309 | Olivetti keyboard (A101/102 key)
PNP030A | AT&T 302 keyboard
PNP030B | Reserved by Microsoft
PNP0320 | Japanese 101-key keyboard
PNP0321 | Japanese AX keyboard
PNP0322 | Japanese 106-key keyboard A01
PNP0323 | Japanese 106-key keyboard 002/003
PNP0324 | Japanese 106-key keyboard 001
PNP0325 | Japanese Toshiba Desktop keyboard
PNP0326 | Japanese Toshiba Laptop keyboard
PNP0327 | Japanese Toshiba Notebook keyboard
PNP0340 | Korean 84-key keyboard
PNP0341 | Korean 86-key keyboard
PNP0342 | Korean Enhanced keyboard
PNP0343 | Korean Enhanced keyboard 101b
PNP0343 | Korean Enhanced keyboard 101c
PNP0344 | Korean Enhanced keyboard 103

Parallel Devices

Device ID | Description
PNP0400 | Standard LPT port
PNP0401 | ECP printer port


Serial Devices

Device ID | Description
PNP0500 | Standard PC COM port
PNP0501 | 16550A – compatible COM port
PNP0510 | Generic IrDA – compatible device


Disk Controllers

Device ID | Description
PNP0600 | Generic ESDI/IDE/ATA – compatible hard disk controller
PNP0601 | Plus Hardcard II
PNP0602 | Plus Hardcard IIXL/EZ
PNP0603 | Generic IDE supporting Microsoft Device Bay specifications
PNP0700 | PC standard floppy disk controller
PNP0701 | Standard floppy controller supporting Microsoft Device Bay specifications

Display Adapters

Device ID | Description
PNP0900 | VGA compatible
PNP0901 | Video Seven VRAM/VRAM II/1024i
PNP0902 | 8514/A compatible
PNP0903 | Trident VGA
PNP0904 | Cirrus Logic Laptop VGA
PNP0905 | Cirrus Logic VGA
PNP0906 | Tseng ET4000
PNP0907 | Western Digital VGA
PNP0908 | Western Digital laptop VGA
PNP0909 | S3 Inc. 911/924
PNP090A | ATI Ultra Pro/Plus (Mach 32)
PNP090B | ATI Ultra (Mach 8)
PNP090C | XGA compatible
PNP090D | ATI VGA Wonder
PNP090E | Weitek P9000 graphics adapter
PNP090F | Oak Technology VGA
PNP0910 | Compaq QVision
PNP0911 | XGA/2
PNP0912 | Tseng Labs W32/W32i/W32p
PNP0913 | S3 Inc. 801/928/964
PNP0914 | Cirrus Logic 5429/5434 (memory mapped)
PNP0915 | Compaq Advanced VGA (AVGA)
PNP0916 | ATI Ultra Pro Turbo (Mach64)
PNP0917 | Reserved by Microsoft
PNP0918 | Matrox MGA
PNP0919 | Compaq QVision 2000
PNP091A | Tseng W128
PNP0930 | Chips & Technologies Super VGA
PNP0931 | Chips & Technologies Accelerator
PNP0940 | NCR 77c22e Super VGA
PNP0941 | NCR 77c32blt
PNP09FF | Plug and Play monitors (VESA DDC)


Peripheral Buses

Device ID | Description
PNP0A00 | ISA bus
PNP0A01 | EISA bus
PNP0A02 | Micro Channel bus
PNP0A03 | PCI bus
PNP0A04 | VESA/VL-bus
PNP0A04 | ACPI Bus


Real-Time Clock, BIOS, System Board Devices

Device ID | Description
PNP0800 | AT-style speaker sound
PNP0B00 | AT real-time clock
PNP0C00 | Plug and Play BIOS (only created by the ROOT enumerator)
PNP0C01 | Motherboard
PNP0C02 | General ID for reserving private resources required by Plug and Play motherboard registers (not specific to a particular device)
PNP0C03 | Plug and Play BIOS event notification interrupt
PNP0C04 | Math coprocessor
PNP0C05 | APM BIOS (version independent)
PNP0C06 | Reserved for identification of early Plug and Play BIOS implementation
PNP0C07 | Reserved for identification of early Plug and Play BIOS implementation


PCMCIA Controller Chip Sets

Device ID | Description
PNP0E00 | Intel 82365 – compatible PCMCIA controller
PNP0E01 | Cirrus Logic CL-PD6720 PCMCIA controller
PNP0E02 | VLSI VL82C146 PCMCIA controller
PNP0E03 | Intel 82365 – compatible CardBus controller


Mouse

Device ID | Description
PNP0F00 | Microsoft bus mouse
PNP0F01 | Microsoft serial mouse
PNP0F02 | Microsoft InPort mouse
PNP0F03 | PS/2-style Microsoft mouse
PNP0F04 | Mouse Systems mouse
PNP0F05 | Mouse Systems 3-button mouse (COM2)
PNP0F06 | Genius mouse (COM1)
PNP0F07 | Genius mouse (COM2)
PNP0F08 | Logitech serial mouse
PNP0F09 | Microsoft BallPoint serial mouse
PNP0F0A | Microsoft Plug and Play mouse
PNP0F0B | Microsoft Plug and Play Ballpoint mouse
PNP0F0C | Microsoft-compatible serial mouse
PNP0F0D | Microsoft InPort-compatible mouse
PNP0F0E | Microsoft-compatible PS/2-style mouse
PNP0F0F | Microsoft Serial BallPoint-compatible mouse
PNP0F10 | Texas Instruments QuickPort mouse
PNP0F11 | Microsoft-compatible bus mouse
PNP0F12 | Logitech PS/2-style mouse
PNP0F13 1 | PS/2 port for PS/2-style mouse
PNP0F14 | Microsoft Kids mouse
PNP0F15 | Logitech bus mouse
PNP0F16 | Logitech SWIFT device
PNP0F17 | Logitech-compatible serial mouse
PNP0F18 | Logitech-compatible bus mouse
PNP0F19 | Logitech-compatible PS/2-style mouse
PNP0F1A | Logitech-compatible SWIFT Device
PNP0F1B | HP Omnibook mouse
PNP0F1C | Compaq LTE Trackball PS/2-style mouse
PNP0F1D | Compaq LTE Trackball serial mouse
PNP0F1E | Microsoft Kids TrackBall mouse
PNP0F1F | Reserved by Microsoft Input Device Group
PNP0F20 | Reserved by Microsoft Input Device Group
PNP0F21 | Reserved by Microsoft Input Device Group
PNP0F22 | Reserved by Microsoft Input Device Group
PNP0F23 | Reserved by Microsoft Input Device Group
PNP0FFF | Reserved by Microsoft Systems
1 The system BIOS should report the PS/2 port, not which type of mouse is connected to that port.


Network Adapters

Device ID | Description
PNP8001 | Novell/Anthem NE3200
PNP8004 | Compaq NE3200
PNP8006 | Intel EtherExpress/32
PNP8008 | HP Ethertwist EISA LAN Adapter/32 (HP27248A)
PNP8065 | Ungermann-Bass NIUps or NIUps/EOTP
PNP8072 | DEC (DE211) Etherworks MC/TP
PNP8073 | DEC (DE212) Etherworks MC/TP_BNC
PNP8078 | DCA 10 Mb MCA
PNP8074 | HP MC LAN Adapter/16 TP (PC27246)
PNP80C9 | IBM Token Ring
PNP80CA | IBM Token Ring II
PNP80CB | IBM Token Ring II/Short
PNP80CC | IBM Token Ring 4/16Mbs
PNP80D3 | Novell/Anthem NE1000
PNP80D4 | Novell/Anthem NE2000
PNP80D5 | NE1000 compatible
PNP80D6 | NE2000 compatible
PNP80D7 | Novell/Anthem NE1500T
PNP80D8 | Novell/Anthem NE2100
PNP80DD | SMC ARCNETPC
PNP80DE | SMC ARCNET PC100, PC200
PNP80DF | SMC ARCNET PC110, PC210, PC250
PNP80E0 | SMC ARCNET PC130/E
PNP80E1 | SMC ARCNET PC120, PC220, PC260
PNP80E2 | SMC ARCNET PC270/E
PNP80E5 | SMC ARCNET PC600W, PC650W
PNP80E7 | DEC DEPCA
PNP80E8 | DEC (DE100) Etherworks LC
PNP80E9 | DEC (DE200) Etherworks Turbo
PNP80EA | DEC (DE101) Etherworks LC/TP
PNP80EB | DEC (DE201) Etherworks Turbo/TP
PNP80EC | DEC (DE202) Etherworks Turbo/TP_BNC
PNP80ED | DEC (DE102) Etherworks LC/TP_BNC
PNP80EE | DEC EE101 (built-in)
PNP80EF | DECpc 433 WS (built-in)
PNP80F1 | 3Com EtherLink Plus
PNP80F3 | 3Com EtherLink II or IITP (8 or 16-bit)
PNP80F4 | 3Com TokenLink
PNP80F6 | 3Com EtherLink 16
PNP80F7 | 3Com EtherLink III
PNP80F8 | 3Com generic EtherLink Plug and Play device
PNP80FB | Thomas-Conrad TC6045
PNP80FC | Thomas-Conrad TC6042
PNP80FD | Thomas-Conrad TC6142
PNP80FE | Thomas-Conrad TC6145
PNP80FF | Thomas-Conrad TC6242
PNP8100 | Thomas-Conrad TC6245
PNP8105 | DCA 10 MB
PNP8106 | DCA 10 MB Fiber Optic
PNP8107 | DCA 10 MB Twisted Pair
PNP8113 | Racal NI6510
PNP811C | Ungermann-Bass NIUpc
PNP8120 | Ungermann-Bass NIUpc/EOTP
PNP8123 | SMC StarCard PLUS (WD/8003S)
PNP8124 | SMC StarCard PLUS with on board hub (WD/8003SH)
PNP8125 | SMC EtherCard PLUS (WD/8003E)
PNP8126 | SMC EtherCard PLUS with boot ROM socket (WD/8003EBT)
PNP8127 | SMC EtherCard PLUS with boot ROM socket (WD/8003EB)
PNP8128 | SMC EtherCard PLUS TP (WD/8003WT)
PNP812A | SMC EtherCard PLUS 16 with boot ROM socket (WD/8013EBT)
PNP812D | Intel EtherExpress 16 or 16TP
PNP812F | Intel TokenExpress 16/4
PNP8130 | Intel TokenExpress MCA 16/4
PNP8132 | Intel EtherExpress 16 (MCA)
PNP8137 | Artisoft AE-1
PNP8138 | Artisoft AE-2 or AE-3
PNP8141 | Amplicard AC 210/XT
PNP8142 | Amplicard AC 210/AT
PNP814B | Everex SpeedLink /PC16 (EV2027)
PNP8155 | HP PC LAN Adapter/8 TP (HP27245)
PNP8156 | HP PC LAN Adapter/16 TP (HP27247A)
PNP8157 | HP PC LAN Adapter/8 TL (HP27250)
PNP8158 | HP PC LAN Adapter/16 TP Plus (HP27247B)
PNP8159 | HP PC LAN Adapter/16 TL Plus (HP27252)
PNP815F | National Semiconductor Ethernode *16AT
PNP8160 | National Semiconductor AT/LANTIC EtherNODE 16-AT3
PNP816A | NCR Token-Ring 4 Mbs ISA
PNP816D | NCR Token-Ring 16/4 Mbs ISA
PNP8191 | Olicom 16/4 Token-Ring Adapter
PNP81C3 | SMC EtherCard PLUS Elite (WD/8003EP)
PNP81C4 | SMC EtherCard PLUS 10T (WD/8003W)
PNP81C5 | SMC EtherCard PLUS Elite 16 (WD/8013EP)
PNP81C6 | SMC EtherCard PLUS Elite 16T (WD/8013W)
PNP81C7 | SMC EtherCard PLUS Elite 16 Combo (WD/8013EW or 8013EWC)
PNP81C8 | SMC EtherElite Ultra 16
PNP81E4 | Pure Data PDI9025-32 (Token Ring)
PNP81E6 | Pure Data PDI508+ (ArcNet)
PNP81E7 | Pure Data PDI516+ (ArcNet)
PNP81EB | Proteon Token Ring (P1390)
PNP81EC | Proteon Token Ring (P1392)
PNP81ED | Proteon ISA Token Ring (1340)
PNP81EE | Proteon ISA Token Ring (1342)
PNP81EF | Proteon ISA Token Ring (1346)
PNP81F0 | Proteon ISA Token Ring (1347)
PNP81FF | Cabletron E2000 Series DNI
PNP8200 | Cabletron E2100 Series DNI
PNP8209 | Zenith Data Systems Z-Note
PNP820A | Zenith Data Systems NE2000 compatible
PNP8213 | Xircom Pocket Ethernet II
PNP8214 | Xircom Pocket Ethernet I
PNP821D | RadiSys EXM-10
PNP8227 | SMC 3000 Series
PNP8228 | SMC 91C2 controller
PNP8231 | Advanced Micro Devices AM2100/AM1500T
PNP8263 | Tulip NCC-16
PNP8277 | Exos 105
PNP828A | Intel '595 based Ethernet
PNP828B | TI2000-style Token Ring
PNP828C | AMD PCNet Family cards
PNP828D | AMD PCNet32 (VL-bus version)
PNP8294 | IrDA Infrared NDIS driver (Microsoft supplied)
PNP82BD | IBM PCMCIA-NIC
PNP82C2 | Xircom CE10
PNP82C3 | Xircom CEM2
PNP8321 | DEC Ethernet (all types)
PNP8323 | SMC EtherCard (all types except 8013/A)
PNP8324 | ARCNET compatible
PNP8326 | Thomas Conrad (all ARCNET types)
PNP8327 | IBM Token Ring (all types)
PNP8385 | Remote Network Access Driver
PNP8387 | RNA Point-to-Point Protocol Driver
PNP8388 | Reserved for Microsoft networking components


SCSI, Proprietary CD-ROM Adapters

Device ID | Description
PNPA002 | Future Domain 16-700 – compatible controller
PNPA003 | Panasonic proprietary CD-ROM adapter (SBPro/SB16)
PNPA01B | Trantor 128 SCSI controller
PNPA01D | Trantor T160 SCSI controller
PNPA01E | Trantor T338 Parallel SCSI controller
PNPA01F | Trantor T348 Parallel SCSI controller
PNPA020 | Trantor Media Vision SCSI controller
PNPA022 | Always IN-2000 SCSI controller
PNPA02B | Sony proprietary CD-ROM controller
PNPA02D | Trantor T13b 8-bit SCSI controller
PNPA02F | Trantor T358 Parallel SCSI controller
PNPA030 | Mitsumi LU-005 Single Speed CD-ROM controller + drive
PNPA031 | Mitsumi FX-001 Single Speed CD-ROM controller + drive
PNPA032 | Mitsumi FX-001 Double Speed CD-ROM controller + drive


Sound, Video Capture, Multimedia

Device ID | Description
PNPB000 | Sound Blaster 1.5 – compatible sound device
PNPB001 | Sound Blaster 2.0 – compatible sound device
PNPB002 | Sound Blaster Pro-compatible sound device
PNPB003 | Sound Blaster 16 – compatible sound device
PNPB004 | Thunderboard-compatible sound device
PNPB005 | Adlib-compatible FM synthesizer device
PNPB006 | MPU401 compatible
PNPB007 | Microsoft Windows Sound System-compatible sound device
PNPB008 | Compaq Business Audio
PNPB009 | New Plug and Play Microsoft Windows Sound System device
PNPB00A | MediaVision Pro Audio Spectrum (Trantor SCSI enabled, Thunder Chip disabled)
PNPB00B | MediaVision Pro Audio 3D
PNPB00C | MusicQuest MQX-32M
PNPB00D | MediaVision Pro Audio Spectrum Basic (no Trantor SCSI, Thunder Chip enabled)
PNPB00E | MediaVision Pro Audio Spectrum (Trantor SCSI enabled, Thunder Chip enabled)
PNPB00F | MediaVision Jazz-16 chip set (OEM versions)
PNPB010 | Auravision VxP500 chip set - Orchid Videola
PNPB018 | MediaVision Pro Audio Spectrum 8-bit
PNPB019 | MediaVision Pro Audio Spectrum Basic (no Trantor SCSI, Thunder chip disabled)
PNPB020 | Yamaha OPL3 – compatible FM synthesizer device
PNPB02F | Joystick/game port

Modems

Device ID | Description
PNPC000 | Compaq 14400 Modem (TBD)
PNPC001 | Compaq 2400/9600 Modem (TBD)


Appendix C Accessibility

This appendix presents recommendations for computer and component design related to lowering access barriers to computer use.

These guidelines were developed in consultation with the Trace Research and Development Center at the University of Wisconsin and based on research funded by the National Institute for Disability and Rehabilitation Research (NIDRR). For more information, see the reference at the end of this appendix.

For information about accessibility guidelines for software, see:

http://www.microsoft.com/windows/enable/


Introduction to Accessibility Recommendations

Personal computers are powerful tools that enable people to work, create, and communicate in ways that might otherwise be difficult or impossible. The vision of making computers easier for everyone to use, however, can be realized only if people with disabilities have equal access to personal computing.

Computer accessibility is becoming an increasingly important issue in the home and workplace. An estimated eight of ten major corporations employ people with disabilities who might need to use computers as part of their jobs. More than 30 million people in the United States alone have disabilities that can be affected by the accessibility of computer software. In addition, as the population ages, more people experience functional limitations that can cause computer accessibility to become a more important issue for everyone. Addressing disabilities in design frequently has benefits for all users, by making tasks simpler.

Legislation in the United States, such as the Americans with Disabilities Act (which affects private businesses with more than 15 employees) and Section 508 of the Rehabilitation Act (which affects the federal government and organizations that receive government funding), has also brought accessibility issues to national attention in both the public and private sectors. Accessibility is also being incorporated into official and international standards for usability, such as ANSI 200. Such recommendations affect the following:

  • Visual displays and indicators
  • Sound
  • Manipulation and physical design
  • Input devices and software controls
  • Labeling
  • Documentation

The rest of this section presents background information related to accessibility issues.


What Are Disabilities?

Individuals are not disabled—rather, some people have difficulties performing certain tasks, such as using a mouse or reading small print. When these limitations are serious enough to impact the person's performance, they are referred to as "disabilities." Anyone can experience the same difficulties because of illness or accident, environment (such as loud background noise), or hardware errors such as a missing mouse.

Disabilities can be divided into the following general categories:

  • Visual impairments. This ranges from slightly reduced visual acuity to total blindness. Those with reduced visual acuity might only need images to be reasonably sized or specially enlarged, or they might need the high contrast between foreground and background. Users with more severe impairments might require output to be translated into audible cues, spoken text, or Braille.
  • Hearing impairments. Some individuals do not notice beeps, distinguish different sounds, or recognize spoken words. These users might require that a computer prompt them in a different manner using a screen flash, an indicator lamp, or a display of messages as text.
  • Movement impairments. Some users are unable to perform certain manual tasks, such as using a mouse or typing two keys at the same time. Others might have a tendency to hit multiple keys, "bounce" fingers off keys, or be unable to hold a printed book. Many users need keyboards and mouse functions to be adapted to their requirements, or they rely exclusively on a single input device.
  • Cognitive impairments. Cognitive impairments take many forms, including short- and long-term memory loss, perceptual differences, and conditions such as Downs syndrome. Language impairments such as dyslexia or illiteracy are also very common. Even people learning the language used by their computer software as a second language can be considered to have a form of language impairment. Proper design can help increase accessibility for computer users with various cognitive and language impairments.
  • Seizure disorders. People with some forms of epilepsy might experience minor or severe seizures when they see visual signals flash at certain rates or hear certain types of random or repetitive sounds.
  • Speech impairments. Although difficulty speaking does not normally affect a person's ability to use a computer today, it can be a problem in using telecommunications and voice menus. Difficulty in speaking might affect normal computer usage more if voice recognition becomes a common form of input in the future.


What Is Accessibility?

Accessibility means making computers accessible to a wider range of users than would otherwise be the case. Special needs can be addressed in several ways:

  • New features built into hardware and operating systems that help make them accessible to users with and without specialized needs. These solutions are often referred to as "electronic curb cuts." These solutions are preferred because the features are available on all workstations and can be used with all applications.
  • Usability features that can be built into mainstream products, making them easier to use for people with disabilities. Examples include customizable colors and keyboard accelerators. In many cases these features also benefit people who do not have disabilities.
  • Utilities that modify the system to help make it more usable by more people, but are not installed on all computers. Examples of utilities include Braille output systems for people who are blind or software that modifies the behavior of the keyboard and mouse.
  • Specialized applications, such as a word processor designed to integrate voice and text, to help individuals with limited reading and writing skills.

A wide variety of hardware and software products have been designed to help people with disabilities make use of personal computers. Among the different types of products available for the Microsoft Windows operating system are the following:

  • Programs that enlarge or alter the color of information on the screen for people with visual impairments
  • Programs that describe information on the screen in Braille or synthesized speech for people who are blind or have difficulty reading
  • Hardware and software utilities that modify the behavior of the mouse and the keyboard
  • Programs that enable users to "type" using a mouse or their voice
  • Word or phrase prediction software that allows typing more quickly with fewer keystrokes
  • Alternate input devices, such as single-switch or puff-and-sip devices, for those who cannot use a mouse or a keyboard

The following sections summarize issues of computer design directly related to a wide range of individual needs for lowering barriers to computer use.


Visual Displays and Indicators

Visual display is the predominant form of display on today's computers. This includes the standard display screen, LED or LCD icon displays on or near the keyboard, and special visual indicators on peripheral devices. For people with low vision or blindness, these displays can pose a barrier to computer use.

When information is displayed on the standard computer screen, special screen-magnification software can increase the image size for people with low vision. Similarly, software "screen readers" can access the information and read it aloud to users who are blind. Information provided by indicator lights or small LCD mini-displays, however, must also be made available and readable by using screen readers or another mechanism.

Hardware design strategies for providing greater access to information presented visually includes the following:

  1. Minimize glare.

    Glare caused by reflections or mismatched color combinations, overly bright indicators, and so on, might present problems for users with low vision. Minimizing glare allows these users greater access to displays.

  2. Avoid 5 to 50 Hz range for the refresh rate or flicker rate.

    Allows users with photosensitive epilepsy, who might have a seizure if exposed to strong stimuli in the 50 Hz range, to more safely use the system.

  3. If possible, make LCD and LED indicators, warning lights, and alert lights readable from software.

    Allows users who are blind to use their screen reading-software to access important indicators, warnings, and notices.

The following standard design practices also facilitate access and use by users with disabilities:

  1. Provide contrast and brightness control.

    Important for users with low vision and color blindness so they can adjust the display to accommodate their needs and preferences.

  2. Provide a display connector for an external or additional monitor.

    Users with low vision often need to augment the system with a larger monitor to take full advantage of their screen enlargement software. This is especially true for users of mobile PCs.

  3. Make the monitor position and angle adjustable.

    Users with physical disabilities adjust the monitor to suit their seating position and approach to the system. Other users with low vision often adjust the monitor to reduce any glare that results from ambient light sources.


Sound

Sound is increasingly being used to convey information important to the operation of a computer. This includes alerts in addition to speech and other complex audio feedback. This can pose problems for any user on an airplane or in other noisy environments, and it can pose a problem for those who are deaf or hard of hearing.

Hardware design strategies for providing greater access to information presented in this fashion include the following:

  1. Provide a headphone jack.

    Allows users with reduced hearing to block out background noise and make the output louder by using headphones or by directly connecting their hearing aids.

  2. Maximize the range of volume adjustment.

    Allows users with reduced hearing to adjust the volume to suit their needs.

  3. Face speakers towards the user.

    Maximizes the signal-to-noise ratio for all users. This is especially important for users with hearing loss.

  4. Provide a visually distinct indicator for all alerts or warning sounds created by hardware.

    Makes recognizing alerts easier for users working in loud environments or for users with deafness or reduced hearing. (Software-generated alerts should be handled by software.)

  5. Provide visual indication of important sounds generated in normal computer operation.

    Some natural sounds, such as those generated by a disk drive or printer, can be important to operation of the systems. Where this is true, some visual indication of the sound should be provided that accomplishes the same purpose so users in loud environments or users with reduced hearing or deafness can effectively use these systems.

  6. Send hardware-generated beeps to the operating system.

    Allows visual display of the beeps for users in loud environments, located in another room, or with reduced hearing or deafness. Examples include beeps related to the keyboard and printer.

  7. Place microphone in the orientation recommended by the microphone manufacturer.

    Along with speech recognition software, this makes the computer more accessible to users who are blind, have low vision, or are physically disabled (including those with Repetitive Strain Injury [RSI] and carpal tunnel syndrome), and for others who have difficulty writing.

  8. Include a speech-capable sound system.

    Provides speech capabilities for nonspeaking persons and also the necessary hardware support for a speech-based access system for people with low vision, blindness, or reading problems.

  9. Make operation of internal components quiet.

    Increases ability of users with neural hearing loss or hearing aids to converse or use computer sound-based features.


Manipulation and Physical Design

Often the focus of accessibility efforts is on the input or display components of a computer. However, many of the physical design characteristics of the computer are equally important. For example, if the person is unable to operate the latches to open a portable computer, the other aspects of the computer's design are of little practical importance.

Some users have conditions that result in weakness or poor movement control. Some have use of just one hand. Some have reduced range of motion or reach.

Hardware design strategies for providing greater access to the physical design of products include the following:

  1. Eject media a sufficient distance for grasping.

    Ejecting 0.5 to 0.75 inch or more is helpful for those with reduced hand functions.

  2. Sculpt or bevel entry slots and so on (including compact disc trays).

    Assists guiding the disk into the slot for those with reduced motor control. This also gives a tactile indicator, which helps those with low vision locate the slot. Compact discs should seat themselves properly if dropped into trays. (That is, no fine positioning is required from the user.) The disc should also be easy to grab from the tray (that is, allow slots at the sides of the tray for placing a finger under the disc to lift it out).

  3. Make latches operable with one hand.

    Allows those who do not have use of limbs or those who use assistive pointing devices to operate the latch.

  4. Keep force required for operation to a minimum (that is, less than 2 Newtons) for inserting and retrieving media.

    Assists those with reduced strength and grasp capability. A maximum force of 2 Newtons is advised, but it is preferable to have the mechanism "suck" the disk in for insertion and not require a force of over 2 Newtons for pulling it out of the slot.

  5. Ensure that media takes rough handling (use caddies for media that does not).

    Allows individuals with poor motor control to safely handle the media.

  6. Provide error flags for misinserted media (especially compact discs).

    When it is not possible to block misinserted media (see description 8 below), the hardware could contain a disk-present detector to warn the user that a disk has been inserted but is unreadable because it is upside-down (and not just in an unreadable format). This would greatly assist users with visual impairments and also novice users.

  7. Ensure that devices do not generate electromagnetic or RF fields that would affect users with hearing aids.

    Assists those users with hearing aids. Electromagnetic fields can couple with induction pick-ups in hearing aids, causing loud or disturbing noises. RF can affect all hearing aids. There are currently no industry standards for these levels, so reasonable care should be taken and testing is recommended.

The following design practices are fairly standard and also facilitate access and use by users with disabilities:

  1. Use media misinsertion blocking.

    Assists all users as a memory aid, but helps especially those with low vision or cognitive impairments who might forget or misinterpret how to insert media (such as upside-down).

  2. Have separate components that allow for use of alternative input devices.

    Assists those who use alternative input or output devices because of the nature of their reduced ability.

  3. Provide adjustable height, swivel, and so on where appropriate.

    Assists those who do not have a full range of movement — displays and input devices can be oriented toward the user.

  4. Have low noise operation.

    In general, quieter components (such as fans, disk drives, and so on) in computers are easier to use for those people with neural hearing loss or those who use hearing aids.

  5. Have no hard edges or corners that could case injury or that could inhibit correct placement.

    Assists those with reduced motor control.

  6. Have no material that can cause an allergic reaction.

    Chromium and nickel are known to cause allergic reactions in some users and should therefore be avoided in any part that users could contact with their skin during normal use.


Input and Controls

The ability to operate or use a computer depends directly on the ability to use its input devices and controls. For many people with physical or visual disabilities, using a computer depends either on the design of the input and control devices or on its ability to substitute other mechanisms for control (such as use different input devices or allow software control). Easier to operate controls are also appreciated by all users, as is the ability to connect and use alternative input devices of their preference.

Users who are blind cannot use input mechanisms that require eye-hand coordination, such as a mouse or a control with no tactile or auditory reference.

Hardware design strategies for providing greater access to input and control functions include the following:

  1. Allow connection, substitution, or addition of alternative input devices (such as keyboards, pointing devices, and so on).

    A second serial port, for example, is helpful for those using SerialKeys software in Windows 95 to provide alternative access as well as for blind users who typically use speech synthesizers with serial connections. As another example, for users who cannot use standard input devices (even with software extensions such as StickyKeys), the availability of an external keyboard and mouse connection on portable systems allows them to substitute specially-designed keyboards or pointing devices.

  2. Make all controls operate from the keyboard.

    This allows users with restricted reach or manipulation to operate controls on the computer, monitor, and so on, that they would otherwise be unable to use. It also allows them to operate the controls from any other keyboard they might use.

  3. Have all controls mounted on the front of the device (that is, facing the user).

    Allows users who have reach limitations to access the controls.

  4. Use push buttons primarily.

    Assists those with reduced motor control and those using head or mouth sticks or other alternative pointing devices.

  5. Use concave buttons (especially where sustained force is required).

    Assists those with reduced finger or motor control (such as tremor) and those who must use headsticks or other pointing devices to operate the buttons. Helps keep finger or pointer from slipping off the button while being pushed.

  6. Avoid twisting motions (instead, use push buttons or edge controls).

    Users with some disabilities, such as cerebral palsy or arthritis, find twisting motions difficult or impossible.

  7. Minimize the force required for operation (that is, less than 2 Newtons).

    Assists those with reduced strength. A maximum force of 2 Newtons for any operation is advised. For controls, use light touch or substitute manual mechanisms with power driven ones for sustained or heavy touch, and require push of less than 2 Newtons.

  8. Make all controls operate with one hand (preferably with one finger or assistive pointing device).

    Allows individuals with use of only one hand or who use assistive pointing devices to operate the controls.

  9. Avoid capacitance-based controls (that is, do not use controls that require skin contact).

    Capacitance-based controls require contact with the human skin. Avoiding these allows users with assistive pointing devices or artificial limbs to use the system.

  10. Use functional grouping and layout of controls.

    Assists those with low vision or cognitive impairments in finding the right keys quickly. Examples of functional sets are direction keys and control keys. They can be grouped by color coding that takes account of color blindness or other design features such as shape or feel.

  11. Make controls tactually discernible.

    This includes locator ridges or nibs on the home keys on the keyboard and the five key on the numeric keypad that assist those who have low vision or are blind. Also, flat membrane keypads with no tactile features should be avoided because these give no feedback on the location of the buttons.

  12. Make the state of non-momentary controls tactually discernible.

    Allows those who have low vision or are blind to discern the state of a control.

  13. Have tactile and audible actuation feedback for controls.

    Allows people who have low vision or who are blind to determine when a key has been pressed.

  14. Avoid keys that cannot be read or simulated by software.

    Allows the use of software programs that can convert simultaneous keystrokes into sequential keystrokes. Many users rely on software programs that either detect or simulate keystrokes. For example, the StickyKeys, SlowKeys, and SerialKeys features in Windows 95 rely on this ability when compensating for a user's difficulty with the keyboard. Blind users can also query the state of toggle keys using software. Any nonstandard keys should produce scan codes that trigger their functionality.

  15. Maximize sizes of controls within the space available.

    Assists those with low vision, and also assists users with limited dexterity who might have difficulty manipulating small controls.

  16. Make the distance between controls sufficient for tactile and visual discrimination.

    Facilitates access by users with visual impairments as well as assisting those with reduced motor control. On keyboards, for example, key top spacing should be approximately one half of the key width. For small controls, spacing can be higher, but functional grouping should be maintained to make it easier to avoid pressing several controls at once.

  17. Have stable controls (for example, intended activation should not change the adjustment state of the control).

    Some users with reduced motor control or blindness might inadvertently change the setting of one control while activating another. Controls or input devices should be designed to avoid this.

  18. Manufacture input guards or provide mounting for guards.

    Keyguards are guards that go over the keyboard and allow users to press one key at a time while resting their hand on the keyguard surface (which allows those with reduced strength and those with reduced motor control to have more control over their input). Guards can also be made for other input devices where applicable. The FilterKeys features in Windows 95 allows direct access for many users, but others benefit further from hardware guards. Manufacturers should also ensure grooves or holes are made in the edge of the device to allow for mounting of a guard.

  19. Provide stable keyboards (for example, nonslip feet).

    Assists those with reduced motor control who might otherwise inadvertently move the keyboard when trying to use it.

  20. Have no left-right bias.

    Assists those who have use of only one hand and those who are left-handed. Where this is not possible (for example, built-in numeric keypads) alternatives should be provided (for example, support for external numeric keypads).


Labeling

The ability to read labels is important to ensure that users are able to detect and recognize controls, connectors, and media interfaces. Users with low vision or blindness often have difficulty if these labels are simply printed in small or low-contrast type. All users have difficulty when these small printed labels are on the back or in hard-to-view areas of a product.

Hardware design strategies for providing greater access to labels include the following:

  1. Use large, high-contrast, bold stroke, sans serif letters, and avoid artwork behind the text.

    Allows users with low vision and older users with reduced vision to more easily see the lettering.

  2. Use tactually distinct icons for controls, connectors, and legends (raised at least 1/32 inch).

    Allows users who are blind to more easily discern an item's label by touch. Also allows any user to identify a component located out of view (such as connectors in the back of the unit).

  3. Provide optional Braille and tactile labels.

    Allows users who are blind the option of customizing the labels on the items.


Documentation

Modern multimedia computers and peripherals require use of documentation more than ever. For users with low vision or blindness, standard print manuals might be unusable. Users with physical disabilities might be unable to hold perfect-bound manuals open. All users would find manuals that are easier to understand a welcome enhancement.

Some documentation design strategies for providing greater access and usability of documentation include the following:

  1. Provide documentation in electronic form (ASCII).

    Enables generation of Braille, speech, and variable-sized text outputs for users with blindness, low vision, and cognitive or physical disabilities.

  2. Provide verbal descriptions of graphical information.

    Allows users with blindness or low vision access to the information contained in the graphic.

  3. Use easily understandable language.

    Benefits everyone, but is especially useful to persons whose first language is sign language or for users with cognitive disabilities.

  4. Use binding that allows the manual to lie open on the table.

    Allows the user to manipulate the document with one hand or a mouthstick.

  5. Provide manuals in alternative formats such as large print (sans serif, 18 point) or Braille.

    Allows users with blindness or low vision access to the information.

  6. Use high-contrast layouts.

    Allows users with color blindness or low vision access to the information.

  7. Use colors that can be copied on copy machines.

    Allows users with low vision the ability to enlarge the information using a copy machine.

  8. Provide online help.

    Allows users to access information without having to refer to manuals.

  9. Avoid conveying information by color alone.

    Allows users with low vision or color blindness to perceive the information, and allows blind individuals to scan the documentation to convert it to ASCII text.


Accessibility Recommendations for PC Design

This section presents summary lists of recommendations for design issues related to access for persons with disabilities. Item numbers are based on lists in related sections in this appendix.

1. Accessibility recommendations for physical design (casing)

Recommended


Input and Controls:

  1. Use push buttons primarily
  2. Use concave buttons (especially where sustained force is required)
  3. Avoid twisting motions (instead use push buttons or edge controls)
  4. Minimize the force required for operation (that is, less than 2 Newtons)
  5. Make all controls operable with one hand (preferably with one finger or assistive pointing device)
  6. Make controls discernible by touch
  7. Have tactile and audible actuation feedback for controls
  8. Maximize sizes of controls within the space available
  9. Make distance between controls sufficient for tactile and visual discrimination


Manipulation and Physical Design:

  1. Sculpt or bevel entry slots and so on (including compact disc trays)
  2. Make latches operable with one hand
  3. Ensure devices do not generate electromagnetic fields that would affect users with hearing aids
  4. Have separate components that allow for use of alternative devices
  5. Use adjustable height, swivel, and so on where appropriate
  6. Have low noise operation
  7. Have no hard edges or corners


Labeling:

  1. Use large, high-contrast, bold stroke, sans serif letters
  2. Use tactually distinct icons for controls, connectors, and legends (raised at least 1/32 inch)
  3. Provide optional Braille and tactile labels


Documentation:

  • All points in the Documentation section of this appendix


Accessibility for PC Card

This section presents a summary of recommendations for design issues related to access for persons with disabilities. Item numbers are based on lists in related sections in this appendix.

2. Accessibility recommendations for PC Cards

Recommended


Labeling:

  1. Use large, high contrast, bold stroke, sans serif letters
  2. Use tactually distinct icons for controls, connectors, and legends (raised at least 1/32 inch)
  3. Provide optional Braille and tactile labels


Documentation:

  • All points in Documentation section in this appendix


Accessibility Guidelines for Input Components

This section presents summary lists of recommendations for design issues related to access for persons with disabilities. Item numbers are based on lists in related sections in this appendix.

3. Accessibility recommendations for pointing devices

Recommended


Input and Controls:

  1. Allow connection, substitution, or addition of alternative input components (that is, keyboards, pointing devices, and so on)
  2. Make all controls operable from keyboard
  3. Use push buttons primarily
  4. Use concave buttons (especially where sustained force is required)
  5. Avoid twisting motions (instead, use push buttons or edge controls)
  6. Keep force required for operation to a minimum (that is, less than 2 Newtons)
  7. Make all controls operable with one hand (preferably with one finger or assistive pointing device)
  8. Avoid capacitance-based controls (that is, controls do not require skin contact)
  9. Use functional grouping or layout of controls
  10. Make controls tactually discernible
  11. Have tactile and audible actuation feedback for controls
  12. Make distance between controls sufficient for tactile and visual discrimination
  13. Have stable controls (that is, intended activation should not change the adjustment state of the control)
  14. Manufacture input guards or provide mounting for guards
  15. Have no left-right bias


Manipulation and Physical Design:

  1. Have separable and interchangeable parts
  2. Have no hard edges or corners
  3. Have no material creating allergies

4. Accessibility recommendations for keyboards

Recommended


Input and Controls:

  1. Allow connection, substitution, or addition of alternative input components (that is, keyboards, pointing devices, and so on)
  2. Make all controls operable from keyboard
  3. Have all controls mounted on the front of the device (that is, facing the user)
  4. Use push buttons primarily
  5. Use concave buttons (especially where sustained force is required)
  6. Avoid twisting motions (instead, use push buttons or edge controls)
  7. Minimize the force required for operation (that is, less than 2 Newtons)
  8. Make all controls operable with one hand (preferably with one finger or assistive pointing device)
  9. Avoid capacitance-based controls (that is, controls do not require skin contact)
  10. Use functional grouping or layout of controls
  11. Make controls tactually discernible
  12. Make the state of non-momentary controls tactually discernible
  13. Have tactile and audible actuation feedback for controls
  14. Avoid keys that cannot be read or simulated by software
  15. Maximize sizes of controls within the space available
  16. Make distance between controls sufficient for tactile and visual discrimination
  17. Manufacture input guards or provide mounting for guards
  18. Provide stable keyboards


Manipulation and Physical Design:

  1. Have separate components that allow for use of alternative devices
  2. Use adjustable height, swivel, and so on where appropriate
  3. Have no hard edges or corners
  4. Have no material creating allergies


Visual:

  1. Make LCD and LED indicators, warning, and alert lights readable from software


Accessibility Guidelines for Display Monitors

This section presents summary lists of recommendations for design issues related to access for persons with disabilities. The following item numbers are based on lists in related sections in this appendix.

5. Accessibility guidelines for display monitors

Recommended


Input and Controls:

  1. Make all controls operable from keyboard
  2. Have all controls mounted on the front of the device (that is, facing the user)
  3. Use push buttons primarily
  4. Use concave buttons (especially where sustained force is required)
  5. Avoid twisting options (instead use push buttons or edge controls)
  6. Minimize force required for operation (that is, less than 2 Newtons)
  7. Make all controls operable with one hand (preferably with one finger or assistive pointing device)
  8. Avoid capacitance-based controls (that is, does not require skin contact)
  9. Use functional grouping or layout of controls
  10. Make controls tactually discernible
  11. Make the state of non-momentary controls tactually discernible
  12. Have tactile or audible actuation feedback for controls
  13. Maximize sizes of controls within the space available
  14. Make distance between controls sufficient for tactile and visual discrimination
  15. Have stable controls (that is, intended activation should not change the adjustment state of the control)


Manipulation and Physical Design:

  1. Make latches operable with one hand
  2. Ensure devices do not generate electromagnetic fields that would affect users with hearing aids
  3. Have separate components that allow for use of alternate devices
  4. Use adjustable height, swivel, and so on, where appropriate
  5. Have low noise operation
  6. Have no hard edges or corners
  7. Have no material creating allergies


Visual:

  1. Minimize glare
  2. Avoid 5 – 50 Hz range for the refresh rate or flicker rate
  3. Make LCD and LED indicators, warning, and alert lights readable from software
  4. Provide contrast and brightness control
  5. Provide a video connector for an external or additional display
  6. Make the display adjustable


Accessibility Guidelines for Audio Components

This section presents a summary of recommendations for design issues related to access for persons with disabilities. All item numbers are based on lists in related sections earlier in this appendix.

6. Accessibility features for headphones

Recommended


Sound:

  1. Provide a headphone jack
  2. Maximize the range of volume adjustment
  3. Provide visual indication of sounds generated in normal computer operation
  4. Send hardware-generated "beeps" to the operating system

7. Accessibility features for microphones

Recommended


Sound:

  1. Place microphone facing the user


Labeling:

  1. Use large, high contrast, bold stroke, sans serif letters
  2. Use tactually distinct icons for controls, connectors, and legends (raised at least 1/32 inch)
  3. Provide optional Braille and tactile labels

8. Accessibility features for speakers

Recommended


Sound:

  1. Maximize the range of volume adjustment
  2. Place speakers facing the user
  3. Include a speech-capable sound system
  4. Make operation of internal components quiet


Accessibility Guidelines for Storage Devices

This section presents summary lists of recommendations for design issues related to access for persons with disabilities. Item numbers in the lists are based on items in related sections in this appendix.

9. Recommendations for 3.5-inch floppy disk drives

Recommended


Input and Controls:

  1. Allow connection, substitution, or addition of alternative input devices (that is, keyboards, pointing devices, and so on)
  2. Make all controls operable from keyboard
  3. Have all controls mounted on the front of the device (that is, facing the user)
  4. Use push buttons primarily
  5. Use concave buttons (especially where sustained force is required)
  6. Avoid twisting motions (instead, use push buttons or edge controls)
  7. Minimize force required for operation (that is, less than 2 Newtons)
  8. Make all controls operable with one hand (preferably with one finger or assistive pointing device)
  9. Make controls tactually discernible


Manipulation and Physical Design:

  1. Eject media a sufficient distance for grasping
  2. Sculpt or bevel entry slots, and so on
  3. Make latches operable with one hand
  4. Minimize force required (that is, less than 2 Newtons) for insertion and retrieval of media
  5. Ensure that media takes rough handling (use caddies for those that cannot)
  6. Provide error flags for misinserted media
  7. Ensure that devices do not generate electromagnetic fields that would affect users with hearing aids
  8. Use media misinsertion blocking
  9. Have low noise operation


Sound:

  1. Provide a visually distinct indicator for all alerts or warning sounds
  2. Provide visual indication of sounds generated in normal computer operation


Labeling:

  1. Use tactually distinct icons for controls, connectors, and legends (raised at least 1/32 inch)
  2. Provide optional Braille and tactile labels


Documentation:

  • All points in Documentation section in this appendix

10. Accessibility recommendations for CD-ROM drives

Recommended


Input and Controls:

  1. Make all controls operable from keyboard
  2. Have all controls mounted on the front of the device (that is, facing the user)
  3. Use push buttons primarily
  4. Use concave buttons (especially where sustained force is required)
  5. Avoid twisting motions (instead, use push buttons or edge controls)
  6. Minimize force required for operation (that is, less than 2 Newtons)
  7. Make all controls operable with one hand (preferably with one finger or assistive pointing device)
  8. Make controls tactually discernible
  9. Have tactile and audible actuation feedback for controls
  10. Maximize sizes of controls within the space available


Manipulation and Physical Design:

  1. Eject media a sufficient distance for grasping
  2. Sculpt or bevel entry slots, and so on (including compact disc trays)
  3. Make latches operable with one hand
  4. Minimize force required (that is, less than 2 Newtons) for insertion and retrieval of media
  5. Ensure that media takes rough handling (use caddies for those that cannot)
  6. Provide error flags for misinserted media (especially CDs)
  7. Ensure that devices do not generate electromagnetic fields that would affect users with hearing aids
  8. Use media misinsertion blocking
  9. Have low noise operation
  10. Have no hard edges or corners


Accessibility Guidelines for Printers

This is a summary liss of recommendations for design issues related to access for persons with disabilities. Item numbers in the lists are based on items in related sections in this appendix.

11. Accessibility for printers

Recommended


Input and Controls:

  1. Allow connection, substitution, or addition of alternative input devices (that is, keyboards, pointing devices, and so on)
  2. Make all controls operable from keyboard
  3. Have all controls mounted on the front of the device (that is, facing the user)
  4. Use push buttons primarily
  5. Use concave buttons (especially where sustained force is required)
  6. Avoid twisting motions (instead, use push buttons or edge controls)
  7. Minimize force required for operation (that is, less than 2 Newtons)
  8. Make all controls operable with one hand (preferably with one finger or assistive pointing device)
  9. Avoid capacitance-based controls (that is, controls do not require skin contact)
  10. Use functional grouping or layout of controls
  11. Make controls tactually discernible
  12. Make the state of non-momentary controls tactually discernible
  13. Have tactile and audible actuation feedback for controls
  14. Maximize sizes of controls within the space available
  15. Make distance between controls sufficient for tactile and visual discrimination
  16. Have no left-right bias


Manipulation and Physical Design:

  1. Eject media a sufficient distance for grasping
  2. Make latches operable with one hand
  3. Minimize force required (that is, less than 2 Newtons) for insertion and retrieval of media
  4. Provide error flags for misinserted media
  5. Ensure that devices do not generate electromagnetic fields that would affect users with hearing aids
  6. Have low noise operation
  7. Have no hard edges or corners
  8. Have no material creating allergies


Sound:

  1. Provide a visually distinct indicator for all alerts or warning sounds
  2. Provide visual indication of sounds generated in normal computer operation
  3. Send hardware-generated beeps to the operating system
  4. Make operation of internal components quiet


Documentation:

  • All points in Documentation section in the "Accessibility" chapter


References and Resources for Accessibility

This section lists some of the references, services, and tools available to help build hardware and software that addresses accessibility needs.


Accessibility Publications

The following publications provide supplementary information.

Berliss, J. R. (1990). Checklists for implementing accessibility in computer laboratories at colleges and universities. University of Wisconsin-Madison, Trace Research and Development Center.

Fontaine, P. (1995). Writing Accessible HTML Documents. General Services Administration.

Lowney, G. C. (1995). The Microsoft Windows Guidelines for Accessible Software Design. Microsoft Corporation.

Novak, M. (Ed.) (1991). General Input Device Emulating Interface: Version 1. University of Wisconsin-Madison, Trace Research and Development Center.

Thoren, Clas (Ed.) (1993). Nordic guidelines for computer accessibility. Gotab, Sthlm.

Vanderheiden, G. C. (1988). Consideration in the design of computers and operating systems to increase their accessibility to persons with disabilities. University of Wisconsin-Madison, Trace Research and Development Center.

Vanderheiden, G. C. (1991). Making software more accessible to people with disabilities. University of Wisconsin-Madison, Trace Research and Development Center.

Vanderheiden, G. C. and Vanderheiden, K. R. (1991). Accessibility Design Guide I: Guidelines for the Design of Consumer Products to Increase Their Accessibility to Persons with Disabilities or Who Are Aging. University of Wisconsin-Madison, Trace Research and Development Center.


Resources for Accessibility Design

This section lists some documents and services that can help with accessibility design.

Microsoft Windows Guidelines for Accessible Software Design

This publication describes techniques for developing software applications that are usable by people with disabilities. This document is included on the Microsoft Developer Network CD-ROM. To obtain additional copies or information about other Microsoft products and services for people with disabilities, contact:

Microsoft Sales Information Center
One Microsoft Way
Redmond, WA 98052-6393
Voice: (800) 426-9400
Text Telephone: (800) 892-5234
Fax: (425) 635-6100

Research and Product Information

For information on research and development concerning technology, communication and disability, or for catalogs of accessibility products and service providers, contact:

Trace Research and Development Center
Waisman Center and Dept. of Industrial Engineering
University of Wisconsin, Madison, WI 53705
E-mail: info@Trace.Wisc.Edu
Fax: (608) 262-8848
FTP, Gopher, and WWW servers at trace.wisc.edu

For a list of listserve discussions, send "LISTS" to listproc@trace.wisc.edu

Documentation in Accessible Formats

The organization Recording for the Blind and Dyslexic, Inc. can assist in preparing documentation in accessible formats, including electronic text and audio tape. Contact:

Recording for the Blind and Dyslexic, Inc.
20 Roszel Road
Princeton, NJ 08540
Voice telephone: (800) 221-4792
Fax: (609) 987-8116

For a list of organizations that can assist in converting documentation into large print or Braille, contact the Microsoft Sales Information Center at the address listed above.

Assistive Technology Programs

For general information and recommendations about how computers can help specific users, consult a trained evaluator who can best match the user needs with the available solutions. An assistive technology program in your area will provide referrals to programs and services that are available to you. To locate the assistive technology program nearest you, contact:

National Information System
Center for Developmental Disabilities
Midland Center
Education Building
8301 Sarrow Road
Columbia, SC 29203
Voice or text telephone: (803) 777-4435
Fax: (803) 935-5250

Closed Captioning and Video Description

The following services can provide assistance in adding closed captions or video description to video tape and film:

The Caption Center
125 Western Avenue
Boston, MA 02134
Voice/text telephone: (617) 492-9225
Fax: (617) 562-0590

National Captioning Institute
5203 Leesburg Pike
Suite 1500
Falls Church, VA 22041


Appendix D Legacy I/O Assignments

This appendix summarizes assignments for IRQ, DMA, and I/O port addresses used by built-in devices on legacy system boards.


Fixed ISA Interrupts

The following IRQs used by ISA devices are considered to be fixed assignments.

Fixed ISA Interrupts

Hardware IRQ | Default assignment
IRQ 0 | System timer
IRQ 1 | Keyboard
IRQ 2 | Second programmable interrupt controller (PIC) cascade
IRQ 3 | COM 2
IRQ 4 | COM 1
IRQ 5 | Sometimes LPT 2 — not considered fixed
IRQ 6 | Standard FDC
IRQ 7 | LPT 1
IRQ 8 | Real-time clock / CMOS
IRQ 9 | —
IRQ 10 | Sometimes COM 4 — not considered fixed
IRQ 11 | Sometimes COM 3 — not considered fixed
IRQ 12 | PC/2-style mouse
IRQ 13 | Coprocessor
IRQ 14 | Primary IDE controller
IRQ 15 | Secondary IDE controller


Legacy ISA DMA Assignments

The following table lists DMA channel assignment used by legacy ISA devices and therefore considered fixed.

Legacy ISA DMA considered fixed

Hardware DMA | System function (default)
DMA 0 | ISA expansion
DMA 1 | —
DMA 2 | FDC
DMA 3 | ECP parallel port on LPT 1
DMA 4 | DMA controller cascading
DMA 5 | —
DMA 6 | —
DMA 7 | —


Legacy ISA I/O Address Assignments

The following table lists I/O addresses used by legacy ISA devices and therefore considered fixed.

Legacy ISA System I/O

I/O Address | Default system function
0000 – 000F | Slave DMA
0010 – 0018 | System
0001F | System
0020 – 0021 | Master 8259
0040 – 0043, 0048 – 004B | PIT #1, PIT #2
0050 – 0052 | System
0060 | Keyboard / mouse controller
0061 | System control port B
0064 | Keyboard / mouse status
0070 – 0071 | NMI Enable / real-time clock
0081 – 008B | DMA page registers
0090 – 0091 | System
0092 | System control port A
0093 – 009F | System
00A0 – 00A1 | Slave interrupt controller
00C0 – 00DE | Master DMA controller
00F0 – 00F1 | Coprocessor busy clear/reset
0170 – 0177 | Secondary IDE controller
01F0 – 01F7 | Primary IDE controller
0201 | Joystick interface
0220 – 022F | Sound Blaster
0278 – 027A | LPT 2 (XT parallel port 3)
02E8 – 02EF | Alternate COM (4)
02F8 – 02FF | COM 2
0330 – 0331 | MPU-401
0376 | IDE Controller
0378 – 037A | LPT 1 (XT parallel port 2)
0388 – 038B | FM synthesis
03B0 – 03BB | MDA, EGA / VGA
03BC – 03BE | LPT 3 (XT parallel port 1)
03C0 – 03DF | EGA / VGA
03E0 – 03E7 | PCIC PCMCIA controllers
03E8 – 03EF | Alternate COM (3)
03F0 – 03F7 | FDC
03F8 – 03FF | COM 1
0534 – 0537 | Windows Sound System-compatible
0CF8 – 0CFB | PCI ports


Glossary


A

ACK

An acknowledgment signal.

Advanced Power Management (APM)

(1) A software interface (defined by Microsoft and Intel) between hardware-specific power management software (such as that located in a system BIOS) and an operating system power management driver. (2) An abridgment of the Advanced Power Management (APM) BIOS Interface Specification title.

Advanced System Configuration and Power Interface (ACPI)

A specification that defines the power management, Plug and Play, and system BIOS interfaces for the system board and operating system.

API

Acronym for application programming interface. This is a set of routines that an applications program uses to request and carry out lower-level services performed by the operating system.

APM

See Advanced Power Management.

Arbitrator

A software module in Windows that handles the allocation of hardware resources among devices.

ASIC

Acronym for application-specific integrated circuit.

ATA

Acronym for AT Attachment. Used interchangeably with Integrated Drive Electronics (IDE).

ATAPI

See AT Attachment Packet Interface.

AT Attachment (ATA)

An integrated bus generally used between host processors and disk drives.

AT Attachment Packet Interface (ATAPI)

A hardware and software specification that documents the interface between a host computer and CD-ROM drives using the ATA bus.


B

buffer

A reserved portion of memory in which data is temporarily held, pending an opportunity to complete its transfer to or from a storage device or another location in memory.

buffering

The process of using buffers to hold data that is being transferred, particularly to or from I/O devices such as disk drives and serial ports.

bus enumerator

A bus device driver that detects devices located on a specific bus and loads information about devices into the hardware tree.


C

Card select number

The handle created by the system BIOS or the operating system through the isolation process, and assigned to each Plug and Play card on the ISA bus as a unique identifier.

Card Services

A system component that is a protected-mode VxD, linked with the PC Card bus driver. The Card Services component passes the event notification from socket services to the PC Card bus driver, provides information from the computer's cards to the PC Card bus driver, and sets up the configuration for cards in the adapter sockets.

CDFS

Compact disc file system, which controls access to the contents of CD-ROM drives.

class

For hardware, the manner in which devices and buses are grouped for purposes of installing and managing device drivers and allocating resources. The hardware tree is organized by device class, and Windows 95 uses class installers to install drivers for all hardware classes.

codec

Compression/decompression technology for digital video and stereo audio.

Compatibility mode

An asynchronous, host-to-peripheral parallel port channel defined in the IEEE 1284-1994 standard. This mode is compatible with existing peripherals that attach to the Centronics-style PC parallel port.

Configuration Manager

The central component of a Plug and Play system that drives the process of locating devices, setting up their nodes in the hardware tree, and running the resource allocation process. Each of the three phases of configuration management — boot time (BIOS), real mode, and protected mode — has its own configuration manager.

conflict

See resource conflict.

CSN

See card select number.


D

DDC

Acronym for display data channel, the communications channel between a monitor and the display adapter to which it is connected. This channel provides a method for the monitor to convey its identity to the display adapter.

device

Any circuit that performs a specific function, such as a parallel port or graphics adapter.

device ID

A device identification string, in many cases beginning with a three-letter standard EISA identifier, that distinguishes each logical device and bus from all others on the system.

device node

The basic data structure for a given device, built by Configuration Manager in Windows 95; sometimes called devnode. Device nodes are built into memory at system startup for each device and enumerator with information about the device, such as currently assigned resources. The complete representation of all device nodes is referred to as the hardware tree.

DIB

Acronym for device-independent bitmap.

digital signal processor (DSP)

An integrated circuit designed for high-speed data manipulations, used in audio, communications, image manipulation, and other data-acquisition and data-control applications.

direct memory access (DMA)

A method of moving data from a device to memory (or vice versa) without the help of the microprocessor. The system board uses a DMA controller to handle a fixed number of "channels," each of which can be used by only one device at a time.

disk I/O controller

A special-purpose chip and circuitry that directs and controls reading from and writing to a computer's disk drive.

DLL

Acronym for dynamic-link library. A programming interface (API) routine that user-mode applications access through ordinary procedure calls. The code for the API routine is not included in the user's executable image. Instead, the operating system automatically modifies the executable image to point to DLL procedures at run time.

DMA

See direct memory access.

dock

To insert a portable computer into a base unit. Cold docking means the computer must begin from a power-off state and restart after docking. Hot docking means the computer can be docked while running at full power.

docking station

The base computer unit into which a user can insert a portable computer to expand it to a desktop equivalent. A typical dock provides drive bays, expansion slots, all the ports on the desktop computer, and AC power.

dongle

A physical device attached to a PC I/O port to add hardware capabilities.

DSP

See digital signal processor.

dynamic detection

The process by which a Plug and Play system can detect that a new device has been added or removed from the PC. This process allows the operating system and applications to begin using the added devices immediately or stop using the removed devices without rebooting the system.


E

ECP

Acronym for extended capabilities port. An asynchronous, 8-bit-wide parallel channel defined by IEEE 1284-1994 that provides PC-to-peripheral and peripheral-to-PC data transfers.

EISA

Acronym for Extended Industry Standard Architecture bus.

Energy Star

Abridgment of EPA Energy Star computers. A program initiated by the U.S. Environmental Protection Agency and computer manufacturers documenting standards of power management designed to reduce the electricity load of computer systems in the commercial sector. Computers that meet the requirements of the Energy Star program qualify for the Energy Star logo.

enumeration

The process by which logical devices and buses, and their available resources, are identified in a Plug and Play system.

enumerator

A Plug and Play system component that takes responsibility for detecting logical child devices and reports the existence of those devices to the configuration manager during startup.

expansion bus

A group of address, data, and control lines that provide a buffered interface to devices located either on the system board or on cards that are plugged into expansion connectors. Expansion buses on the system board can include the USB, PC Card, PCI, and other buses.

expansion card

A card that connects to an expansion bus and that contains one or more devices.

expansion ROM

See option ROM.


F

FDC

Acronym for floppy disk drive controller.

FIFO

Acronym for first in, first out. A method for processing a queue in which items are removed in the same order they were added.


H

Hardware Compatibility Tests

A suite of tests prepared by Windows Hardware Quality Laboratory (WHQL) that verify hardware and device driver operation under a specific operating environment. These tests exercise the combination of a device, a software driver, and an operating system under controlled conditions to verify that all components operate properly.

hardware tree

A record in RAM of the current system configuration, based on the configuration information for all devices in the hardware branch of the Registry. The hardware tree is created each time the computer is started or whenever a dynamic change occurs to the system configuration.

HCT

See Hardware Compatibility Tests.

HDC

Acronym for hard disk controller. See Disk I/O Controller.

hot docking

A system design to support removing or installing a mobile system in a docking station, while the computer is running at full power.


I

IDE

Acronym for Integrated Device Electronics. A type of disk-drive interface where the controller electronics reside on the drive itself, eliminating the need for a separate adapter card.

IHV

Acronym for independent hardware vendor.

I/O

Acronym for input/output. Two of the three activities that characterize a computer: input, processing, and output. This refers to the complementary tasks of gathering data for the microprocessor to work with and making the results available to the user through a device such as the monitor, disk drive, or printer.

INF file

A file created for a particular adapter that provides the Windows Setup program with the information required to set up that device, such as a list of valid logical configurations for the device, the names of driver files associated with the device, the values to be added or changed in the registry, and so on.

integrated devices

Any devices, such as parallel ports, graphics adapters, and so on, that are designed on the system board rather than on an expansion card.

IPL

Acronym for initial program load. A device used by the system during the boot process to load an operating system into memory.

IrDA

Acronym for Infrared Data Association.

IRP

Acronym for I/O request packet. Data structures that drivers use to communicate with each other.

IRQ

Acronym for interrupt request. A method by which a device can request to be serviced by the device's software driver. The system board uses a programmable interrupt controller (PIC) to monitor the priority of the requests from all devices. When a request occurs, the microprocessor suspends the current operation and gives control to the device driver associated with the interrupt number issued. The lower the number for example, IRQ 3, the higher the priority of the interrupt.

ISA

Acronym for Industry Standard Architecture bus. An expansion bus that provides a buffered interface from devices on expansion cards to the PC internal bus.

isolation

The process by which cards on an ISA bus are distinguished from each other after system startup.


K

kernel

The portion of Windows that manages the processor.


L

legacy

A colloquial description usually referring to older devices or systems that are not Plug and Play compatible.

local bus

Generally refers to a system bus directly connected to the microprocessor on a system board. Used colloquially to refer to system board buses located closer to the microprocessor than are ordinary expansion buses (that is, with less buffering), which are therefore capable of greater throughput. The PCI bus is often referred to as a local bus.


M

minidriver

A device driver that contains hardware-specific code related to a specific hardware device. The Win32 Driver Model allows hardware manufacturers to implement minidrivers.

miniport driver

A 32-bit installable driver. Windows NT was the first operating system to use miniport drivers.

motherboard

See system board.

MPEG

Acronym for Motion Picture Experts Group, used when referring to one of several standard video-compression schemes.


N

NDIS

Acronym for Network Driver Interface Specification. NDIS provides transport independence for network vendors. All transport drivers call the NDIS interface to access network.

nibble mode

An asynchronous, peripheral-to-host channel defined in the IEEE 1284-1994 standard. This mode provides a channel for the peripheral to send data to the host, which is commonly used to identify the peripheral.

NMI

Acronym for Nonmaskable Interrupt. An interrupt that cannot be overruled by another service request; called nonmaskable because it bypasses and takes priority over interrupt requests generated by software, the keyboard, and other devices.

NTFS

Windows NT File System. An advanced file system designed for use specifically with the Windows NT operating system. NTFS supports file system recovery and extremely large storage media, in addition to other advantages.


O

OEM

Acronym for original equipment manufacturer, used in this guide primarily to refer to PC systems manufacturers.

option ROM

Optional read-only memory found on expansion cards. This ROM usually contains additional firmware required to properly boot the peripheral connected to the expansion card, for example, a hard drive. Also referred to as an expansion ROM.


P

packed-pixel frame buffer

A portion of the display memory that holds the contents of a single screen image with screen bits stored in a single plane, with each pixel on the screen having a set of two or more corresponding bits that define the pixel color.

PCI

Acronym for Peripheral Component Interconnect. A high-performance 32-bit or 64-bit bus designed to be used with devices that have high bandwidth requirements, such as the graphics subsystem.

PCMCIA

Acronym for Personal Computer Memory Card International Association. Usually used to refer to a controller for PC Card expansion cards as documented in the PCMCIA standards.

PIC

Acronym for programmable interrupt controller.

Planar

See system board.

Plug and Play

A design philosophy and a set of specifications that describe hardware and software changes to the PC and its peripherals for automatically identifying and arbitrating resource requirements among all devices and buses on the system.

PnP

See Plug and Play.

port

A connection or socket used to connect a device such as a printer, monitor, or modem to the computer. Information is sent from the computer to the device through a cable.

port replicator

Low-cost docking station substitute, intended to provide convenient, one-step connection to multiple desktop devices.

POST

Acronym for power-on self test. A procedure of the system BIOS that identifies, tests, and configures the PC in preparation for loading the operating system.


R

RAMDAC

Acronym for random access memory digital-to-analog converter. A chip built into some VGA and SVGA display adapters that translates the digital representation of a pixel into the analog information needed by the monitor to display it. The presence of a RAMDAC chip generally enhances overall display performance.

Red Book audio

The data format standard for conventional audio CDs used in home stereo systems.

registry

The tree-structured hierarchical database in which system hardware and software settings are to be stored. The registry supersedes use of separate INI files.

resource arbitrator

A set of functions used by Configuration Manager to arbitrate and allocate resources on the PC.

resource conflict

The result of more than one device sharing the same non-sharable resource. Conflicts can cause the device to be partially functional or nonfunctional, or might cause the PC to malfunction completely.

resource data type function

A function that describes the resource requirements of an ISA expansion card, along with the programmability available on the card and its interdependencies.

resources

A general term that refers to interrupt request (IRQ) signals, direct memory access (DMA) channels, I/O port addresses, and memory addresses.

RLE

Acronym for run-length encoding, a data compression scheme technique in which successive bytes of identical data are converted to a 2-byte pair, consisting of the repeated data byte and the repeat count.


S

SCAM

Acronym for SCSI configured automatically.

SCSI

Acronym for small computer system interface. An I/O bus designed as a method of connecting several classes of peripherals to a host system without requiring modifications to generic hardware and software.

SPI

Acronym for SCSI-3 parallel interfaces.

spin down

A power management capability in which a hard drive shuts down its spindle motor.

static resources

Device resources, such as IRQ signals, DMA channels, I/O port addresses, and memory addresses, that cannot be configured or relocated.

system board

The primary circuit board in a PC that contains most of the basic components of the system. Also referred to as motherboard or planar.


T

TAPI

Acronym for telephony application program interface. A set of calls that allows applications to control modems and telephones by routing application function calls to the appropriate "service provider" DLL for a modem.

tuple

A data structure defined by the PCMCIA to describe a single, specific characteristic of a PC Card. Tuples are chained together to form the card information structure (CIS), which describes to system software the PC Card's resource requirements and other characteristics. Tuples consist of a tuple code, an offset to the next tuple, and a number of bytes specific to the tuple.


U

UART

Acronym for universal asynchronous receiver-transmitter. A module composed of a single integrated circuit that contains both the receiving and transmitting circuits required for asynchronous serial communication.

Unimodem

Name used to refer to the Windows universal modem driver. It is a driver-level component that uses modem description files (INFs) to control its interaction with the communications driver.

Universal Serial Bus

A bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, serial and parallel ports, and input devices on a single bus.

USB

Acronym for Universal Serial Bus.


V

VESA

Acronym for Video Electronics Standards Association.

VxD

A device driver that runs at the privileged ring 0 protected mode of the microprocessor. These drivers can extend the services of the Windows kernel, supervise hardware operations, or perform both functions. Such driver files are usually named according to the scheme VxD, where x refers to the device or service supported.


W

warm docking

A system design to support removing or installing a mobile system in a docking station while in a reduced power state such as suspend.

Win32 API

A 32-bit application programming interface for both Windows 95 and Windows NT that includes sophisticated operating system capabilities, security, and API routines for Win32-based applications.

workstation

In general, a powerful computer having considerable calculating and graphics capability.