PC 2001 System Design Guide

A Technical Reference for Designing PCs and Peripherals for the Microsoft® Windows® Family of Operating Systems

Intel Corporation and Microsoft Corporation

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

Intel Corporation and 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.

Intel and Microsoft do not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Intel and Microsoft disclaim 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, Intel and Microsoft do 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. Intel and 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.

ClearType, Direct3D, DirectDraw, DirectInput, DirectMusic, DirectShow, DirectSound, DirectX, Microsoft, Microsoft Press, MS-DOS, Win32, Win64, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Intel is a registered trademark of Intel Corporation.

Other product and company names herein may be the trademarks of their respective
owners.

© 1999-2000 Intel Corporation and Microsoft Corporation. All rights reserved.


About the Design Guide

Welcome to the PC 2001 System Design Guide. This chapter tells you about the document and gives you background information to help you understand its contents.

IMPORTANT: The requirements in this guide provide guidelines for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft® Windows® Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

Purpose

This guide is for engineers who design and build personal computers, expansion cards, and peripheral devices to be used with the Microsoft Windows 2000 and Windows Millennium Edition (Windows Me) operating systems. Hardware design following the requirements in this document provides the user with an optimal experience when the hardware is used with the Windows family of operating systems.

PC 2001 requirements apply to all PC client systems, such as desktop, mobile, and workstation systems. In this edition of the design guide, the design requirements apply to the following:

  • Specific types of systems that will run either Windows 2000 or Windows Me operating systems
  • Systems adopting the goals of the Easy PC Initiative, including requirements for legacy-free PC systems
  • Devices supported under Windows Me and Windows 2000, including graphics and video device capabilities, digital media, storage, networking and communications, and other devices

This guide does not address PC systems designed to act as servers in networked environments, nor does it address non-PC handheld computers running the Microsoft Windows CE operating system.

History

This guide is co-authored by Intel Corporation and Microsoft Corporation. The requirements in this guide indicate features that the hardware industry should consider in designing PCs and peripherals for various price levels and performance levels.

To promote industry participation in each design guide, Intel Corporation and Microsoft Corporation sponsor the PC Design Guide web site to provide information for engineers, managers, and others in the PC and hardware peripheral industry who are interested in the PC design guideline projects. This site presents up-to-date information about current design guide projects, including interim drafts and review events.

Changes from PC 99

The clarifications, changes, and additional requirements in this guide include extensions and modifications to the requirements defined in PC 99 System Design Guide (Microsoft Press®, 1998; ISBN 0-7356-0518-1).

Unlike PC 99, the PC 2001 System Design Guide contains no recommendations. Any recommended items from the previous guide have become requirements or they have been removed. Redundant requirements have been removed or consolidated in one part of the guide.

The PC 2001 System Design Guide introduces the Easy PC initiative and provides some of the requirements for legacy removal supporting the Easy PC vision. For example, Chapter 3, "PC System," contains seven new requirements for legacy-free systems.

Guideline Tracking

When a technology matures or becomes obsolete, those guidelines are removed from the system design guide. For example, the PC System chapter contains a high-level requirement for PC Card and CardBus, the detailed requirements are not in the PC 2001 System Design Guide because that technology is well known and the information about it is available on http://www.pcdesguide.org.

To make guideline tracking easier, each requirement is assigned an alphanumeric identifier. These identifiers are unique and are retired with the requirement when that requirement becomes obsolete. Appendix C, "PC 2001 Master Checklist," provides a list of current requirements with their PC 99 numbers and indicates those PC 99 requirements that have been retired in this guide.

Back to top Back to top


How to Use This Guide

The PC 2001 requirements are defined by system architecture and for individual bus classes and device classes. Requirements are derived from initiatives that are shared between Intel and Microsoft. The goal of such initiatives is an improved user experience. The chapter in the initiative section sets the context for future requirements. The current requirements are in the platform and device class subsystem chapters.

Requirement numbering has evolved since the original design guide. In PC 2001, requirement identifiers are assigned according to an alphanumeric scheme. The numbers are not necessarily sequential. Each requirement has a permanent mnemonic and number combination as follows:

mnemonic—item number.subitem

The mnemonic is a shorter version of the name for a technology. A listing of the mnemonics is included in Appendix C.

PC 2001 Design Guide Organization

This design guide is divided into three parts.

  • Part 1: Initiatives. Introduces the initiatives for PC 2001. Study this part first to understand the key design issues and initiatives addressed in the PC 2001 requirements.
  • Part 2: Platform Requirements. Presents system-type definitions and requirements for each system type. Study this part for an understanding of the overall system requirements.
  • Part 3: Device Class Subsystem Design Requirements. Presents requirements for each device class supported under Windows 2000. Study this part for a detailed understanding of how devices are implemented on PC 2001 systems.
  • Appendixes. Includes the PC 2001 checklist, which summarizes all of the requirements defined in this guide, plus other technical and referential appendixes.

Chapter 1, "Executive Summary," provides a quick overview of the key requirements in the PC 2001 guide.

Terms and Conventions Used

System designers must implement the basic requirements presented in PC 2001 System Design Guide on all systems.

Requirement statements that begin with the phrase "If implemented…" indicate a feature that is not required, but must comply with the stated requirements if the manufacturer includes that feature. These features add capabilities that are supported by the Windows family of operating systems, and they take advantage of the native capabilities of the drivers included with the operating system.

IMPORTANT: The requirements in this guide are often provided in the form of references to industry specifications. These specifications might contain intellectual property of Intel, Microsoft, or other third parties. Each of these industry specifications might have different intellectual property licensing arrangements. It is the responsibility of the original equipment manufacturer (OEM) to consult these industry specifications or their issuance bodies for licensing specifics or details.

The following conventional terms are used throughout this guide. In addition, see the "Glossary" at the back of this guide.

Convention | Meaning
Add-on device | Refers to devices that are traditionally added to the basic PC system to increase functionality. Examples include audio, networking, graphics, small computer system interface (SCSI) controller, and so on. Add-on devices fall into two categories: devices built onto the system board and devices on expansion cards added to the system through a system-board connector, such as Peripheral Component Interconnect (PCI).
System device | Also on-board device. Refers to 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 drive controller (FDC), hard disk controller (HDC), serial and parallel ports, PCI bridges, and so on. These devices are typically integrated with the supporting chip set in legacy PC designs.
Windows | For PC 2001, refers to both Microsoft Windows Me and Windows 2000 Professional operating systems.
Windows Me | For PC 2001, refers specifically to the Microsoft Windows Millennium Edition operating system, including any add-on capabilities of the operating system.
Windows 2000 | For PC 2001, refers specifically to the Microsoft Windows 2000 Professional operating system, including any add-on capabilities and any later versions of the operating system.

Clarifications and Updates

Updates to PC 2001 and other PC design guides, technical clarifications, and answers to frequently asked questions are on the PC Design Guide Web site listed in "References" at the end of this chapter.


PC 2001 and the "Designed for Microsoft Windows" Logo Program

Microsoft will refer to the requirements in this guide when defining requirements for the "Designed for Microsoft Windows" Logo Program for hardware. The "Designed for Microsoft Windows" Logo Program was developed by Microsoft to help end users easily identify hardware and software products designed specifically for the Windows Me and Windows 2000 Professional operating systems. For information about current Windows logo programs, see the Microsoft Windows Logo Program for Hardware listed in "References" at the end of this chapter.

Licensing the "Designed for Microsoft Windows" Logo enables vendors to use the logo on web sites, product packaging, advertising, collateral, and other marketing materials. The "Designed for Microsoft Windows" Logo indicates to customers that the product is designed to meet a specific set of standards and to provide an optimal experience when run on either the Windows Me or Windows 2000 Professional operating system.

Logo Compliance Dates. In general, the "Designed for Microsoft Windows" Logo requirements related to PC 2001 guidelines go into effect with the release of Windows Whistler except when the effective date is otherwise stated, such as chip set requirements that have an effective date of July 1, 2001. Compliance testing for some requirements will begin later because of the time required for supporting parts to become widely available. For information about actual compliance testing dates for specific requirements, see the Windows Logo Program Requirements at http://www.microsoft.com/hwdev/winlogo/.

Logo Testing. Both hardware and software are tested before rights are granted for using the "Designed for Microsoft Windows" Logo. The testing organization for the Logo Program is the Windows Hardware Quality Laboratory (WHQL), which provides compatibility testing services for Windows hardware and drivers. WHQL produces test kit releases based upon the current Windows Logo requirements document.

This document does not explain how a guideline will be tested. Microsoft and Intel co-sponsor the System Test Implementers Forum, wherein industry sources collaborate on test criteria and development. For test information, see the references list in the following section.


References

The following table lists some of the information resources, services, and tools that are available from Intel and Microsoft to help build hardware that complies with the PC 2001 requirements. In addition, each chapter in this guide contains a reference section listing the supporting documents for that chapter. Appendix D, "Master Reference List," provides a comprehensive list of all references for the guide.

Intel information for developers

http://developer.intel.com

Microsoft information for hardware manufacturers

http://www.microsoft.com/hwdev/
E-mail: ihv@microsoft.com

Microsoft Windows Hardware Quality Laboratory testing tools

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

Microsoft Windows Logo Program for Hardware

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

PC Design Guides

http://www.pcdesguide.org

System Test Implementers Forum

http://www.systemtest.org

Windows Me and Windows 2000 Driver Development Kits (DDKs)

http://www.microsoft.com/ddk/
Also provided with Microsoft Developer Network (MSDN) Professional membership. To subscribe:
http://www.microsoft.com/msdn/subscribe/

Windows Logo Program Requirements

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


Chapter 1 Executive Summary

PC 2001 System Design Guide contains hundreds of requirements for PC systems designed for 2001–2002. This chapter provides a summary of those requirements and of the areas that differ from PC 99.

PC 2001 System Design Guide provides OEMs with requirements for computer systems designed for delivery in the middle of 2001. Co-authored by Intel and Microsoft, the requirements in this guide indicate features that the hardware industry must consider when designing PCs and peripherals. These hardware designs provide the user with an optimal experience when the hardware is used with the Microsoft Windows family of operating systems.

The requirements apply to the platform as a whole and to the technologies that make up the complete system. The clarifications, changes, and additional requirements in this guide include extensions to and modifications of the requirements defined in PC 99 System Design Guide. General differences between PC 2001 and PC 99 guides are:

  • PC 2001 contains only requirements, with no recommendations. Some requirements apply only if the manufacturer implements that technology in the system. Such requirements are identified by the words "If implemented" in the requirement. For example, a system is not required to include IEEE 1394 connectivity, only to follow the cited IEEE standards if it does.
  • Requirements for mature or well-understood technologies have been removed to the library section of the PC Design Guide Web site. For example, the following topics have been repeated throughout the recent history of PC design guides and essentially would have been unchanged for this new edition, so they are now collected in a reference library at the following web sites:

Legacy Plug and Play Guidelines
http://www.pcdesguide.org/LegacyPnP/

PC Card and CardBus Guidelines
http://www.pcdesguide.org/library/pccard.htm

  • Some requirements have been removed because those features are no longer important to the industry, or they are no longer relevant in defining the optimal user experience with the Windows operating system.
  • New requirements describe technologies for which support is planned in the Windows family of operating systems.
  • Requirements pertaining to specific PC market classifications have been minimized. PC 2001 identifies requirement differences for mobile PCs and workstations systems where applicable.


Platform Requirements Summary

This section provides a summary the PC system requirements for PC 2001. The complete requirements are in Chapters 3 through 5 of this guide.

The following table and list provide a summary of the requirements for the generic PC system, often a desktop computer, with variations for mobile and high performance systems, often called workstations. Mobile computers and workstations are based on the PC system requirements. Chapter 4, "Workstation," and Chapter 5, "Mobile," point out differences.

System Requirements

 | PC System Requirements | Additions or Differences for:
 |  | Workstation | Mobile
Processor complex | 667 MHz | 700 MHz Additional requirements for multiprocessor, if implemented | 400 MHz Additional battery and docking requirements
 | APIC enabled | No additional requirements | APIC not required
Cache | 128 KB | 256 KB | No additional requirements
Memory (RAM) | 64 MB, 128 MB for systems designed for Windows 2000 | 128 MB RAM expandable to 2 GB | No additional requirements
Power management (see text following table) | ACPI 1.0b | No additional requirements | Mobile PC supports Smart Battery or ACPI Control Method battery
Expansion Bus | USB required PCI, SCSI, optional ISA prohibited | Additional requirements for 64-bit PCI bus, bridges, and adapters, if implemented PCI-X optional | No additional requirements
Ports | 2 USB available to user | No additional requirements | 1 USB available to user
Graphics subsystem | Video playback capability required DVI, analog video input, and capture requirements, if implemented | Larger screen size Follows AGP Pro Bus 1.1 specification, if implemented | Mobile PC has an integrated display
Storage subsystem | Hard disk and CD or DVD required | Multiple hard disk requirements, if implemented | Hard disk is primary boot device

The system board must support Advanced Configuration and Power Interface Specification, Version 1.0b, for power management and Plug and Play. If software fan control is implemented, thermal design and fan control comply with ACPI 1.0b.

Devices appear off when in the sleep state; indicators show whether the system is asleep or awake. The system must support S3, S4, and S5 states. The Universal Serial Bus (USB) host controller and all devices that support wakeup capabilities must support wakeup from all sleep states in the range of S1-S3. Mobile systems, however, are not required to wake from S3 or S4.

BIOS provides support for OnNow and Instantly Available capabilities. Requirements include support for local, network, and remote boot, all calendar dates, security, updates, and debugging. BIOS and option ROMs support Int 13h extensions.

System and devices must comply with requirements for accessibility, Plug and Play, and driver installation. Support for a local area network (LAN) connection and public network communications is required.

Required technologies, such as USB or graphics, follow published standards, as cited in those chapters.


Legacy Reduction and Removal

All PC 2001 computers accomplish some level of legacy reduction. With few exceptions, PC 2001 systems meet the following legacy reduction requirements:

  • No ISA slots or devices
  • Peripherals offer non-legacy connections
  • No reliance on Microsoft MS-DOS® for any software components provided with the system

Systems that are identified by the operating system as "legacy free" must meet the following additional legacy-removal requirements:

  • No boot dependencies on ISA or other legacy devices.
  • No operating system detection or user-accessible connectors for external serial, parallel, legacy FDC, or PS/2 ports, and no use of related port addresses.
  • BIOS support for ACPI changes to support legacy and 8042 flags, ACPI reset mechanism, and the debug port table.


Device Class Subsystem Requirements Summary

The following list provides a summary of the technology requirements for each device class supported under Windows 2000. The complete requirements are in chapters 6 through 16 of the guide.

Buses

The following requirements are introduced in PC 2001 System Design Guide.

  • Bluetooth is introduced as a cable replacement technology.
  • If a networking device is implemented with a Bluetooth interface, the Network Driver Interface Specification 5.0 (NDIS) requirement for networking devices is relaxed.
  • 1394 interfacing requirements are clarified.

The following requirements are unchanged from the PC 99 System Design Guide.

  • Plug and Play requirements
  • Power management requirements
  • Device driver requirements


Input Devices

The following requirement is introduced in PC 2001 System Design Guide.

  • All non-integrated USB input devices comply with the Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1.

The following requirements are unchanged from the PC 99 System Design Guide.

  • Legacy ports are discouraged; USB replaces legacy serial and parallel ports as the dominant connector. If implemented, legacy ports adhere to strict requirements for PC 2001 systems.
  • All devices meet the Plug and Play, power management, and other specifications for their device class and bus connectors.
  • Smart card devices comply with International Organization for Standardization (ISO) 7816 requirements.
  • The system must provide a separate, physically isolated transceiver for each infrared (IR) protocol supported.


Graphics

The following requirements are introduced in PC 2001 System Design Guide.

  • If an external digital interface is implemented, it must comply with Digital Visual Interface (DVI) specifications, for both graphics adapters and monitors.
  • Systems must support a minimum resolution of 1024 × 768, 32 bits per pixel (bpp), double buffered in 2-D mode, and 1024 × 768, 16-bit bpp, double buffered, 32-bit Z in 3-D mode. Desktop systems must support hardware-accelerated 3-D graphics.
  • Clarifications are provided for external display interface, color management, and 2-D requirements for the graphics adapter.
  • The 3-D acceleration requirements match current state of the industry and Microsoft DirectX® implementation.
  • Clarifications are provided for TV output, if this is implemented in the system.
  • Clarifications and quality advances are provided for graphics subsystem support for video, such as support for TV/DVD playback.
  • Specific implementation guidelines are provided for mobile PC systems.

The following requirements are unchanged from the PC 99 System Design Guide.

  • Plug and Play, power management, and multiple monitors and multiple adapter requirements.


Video

The following requirements are introduced in PC 2001 System Design Guide.

  • For all desktop PC 2001 systems (including workstations), most graphics and video capabilities must be fully supported at 1024 × 768, 32 bpp mode or better.
  • Systems with DVD-Video playback capabilities must correctly implement digital video disk (DVD) decoders to ensure seamless navigation and quality decoding.
  • All streams (including data streams) received by receiver modules must be available to the host.
  • Systems that support digital TV must have All Format Moving Picture Expert Group (MPEG) decode support (that is, decode support for up to six times standard definition rates).
  • Clarifications are provided related to the ever-increasing demand for improved video quality on the PC platform.


Monitors

The following requirements are introduced in PC 2001 System Design Guide.

  • Compliance with VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1, Level 2B, and VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A, is required.
  • Both digital and analog monitors must be compliant with the VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1, Level 2B protocols (DDC2B) and support Image Color Management (ICM), with resolution requirements based on monitor size.
  • Digital interface, if implemented, must be DVI compliant, with additional requirements for power state transitions and hot plug detection.
  • Monitors must provide International Color Consortium (ICC) profile information.


Audio

The following requirements are introduced in PC 2001 System Design Guide.

  • Some audio minimum performance requirements are increased from the levels in the PC 99 System Design Guide.
  • Performance and feature requirements are defined for 2-D and 3-D hardware acceleration and Downloadable Sound (DLS) acceleration, if these capabilities are implemented.
  • Clarifications and new requirements for microphone input to support voice-input applications.
  • Mobile audio exceptions and adaptations for docked mobile PCs are added.

The following requirements are unchanged from PC 99 System Design Guide.

  • Audio hardware does not use legacy interfaces.
  • As defined in previous design guides, digital audio requirements specify audio buffer management guidelines and other features to ensure the system is digital ready.


Storage

The following requirements are introduced in PC 2001 System Design Guide.

  • USB devices must comply with the USB mass storage specification.
  • Discrete PCI AT Attachment (ATA) controllers implemented in docked mobile PCs provide native mode support as defined in the PCI IDE Controller Specification, Version 1.0.
  • Clarifications for CD drives, which must comply with Multimedia Command Set 2 (MMC2), support multisession capabilities, and detect digital audio.
  • Clarifications for DVD drives, which must meet CD drive read compatibility requirements.
  • Requirements for CD and DVD read rates are altered to allow faster, broader acceptance of CD-Recordable (CD-R), CD-Re-Writable (CD-RW), and DVD rewriteable formats where error correction and defect management are imperative.

The following requirements are unchanged from PC 99 System Design Guide.

  • Installation, power management, and driver requirements.
  • Storage components and optical devices must support bus mastering, and most device types must support media status notification.


Modems

The following requirements are introduced in PC 2001 System Design Guide.

  • Minimum modem support includes specified commands from the V.250 AT command set.
  • Integrated Services Digital Network (ISDN) modem must support basic AT commands plus commands to select the end-to-end protocol, set switch type, and choose subscriber numbers. ISDN modems must also support Request for Comments (RFC) 1662.
  • All external USB modems (including ISDN modems) must support Universal Serial Bus Specification, Revision 1.1, and Universal Serial Bus Device Class Definitions for Communications Devices, Version 1.0, or the standards for the bus to which they are attached.
  • Requirements are provided for:
  • Telephone Device for the Deaf (TDD) support, voice mode, and Caller ID, if implemented
  • Mobile modems that implement wireless or digital cellular support
  • Telephony applications included with a PC 2001 system

The following requirements are unchanged from PC 99 System Design Guide.

  • Requirements for Plug and Play, power management (including wake-on-ring), and installation.
  • Modem drivers must include Unimodem support.
  • Driver-based modems must use a Windows Driver Model (WDM) driver solution.


Networking

The following requirements are introduced in PC 2001 System Design Guide.

  • Network adapters on a system with Windows 2000 preinstalled must provide Preboot Execution Environment (PXE) Specification, Version 2.1, remote boot support.
  • Home networking guidelines specify which LAN adapter requirements apply for adapters intended for home markets. Home networking media must support IP and related specifications for media choice, such as Home Radio Frequency (HomeRF) or Home Phoneline Networking Alliance (HomePNA).
  • New requirements cite specifications for wireless networking, Digital Subscriber Line (DSL) modems, and CAP/QAM Asymmetric Digital Subscriber Line (ADSL) modems.

The following requirements are retained from PC 99 System Design Guide:

  • All network adapters must use an NDIS 5.0 miniport driver.
  • The adapter must detect the network dynamically, sense transceiver type, and meet other standard requirements for data transmission when the technology supports detection.
  • All external networking devices using USB or IEEE 1394 must use corresponding standard control protocols.
  • Plug and Play, power management (including Wake-on-LAN), and driver installation are unchanged.
  • Minimal changes were made to requirements for IEEE 802 LAN, ISDN, cable modems, asynchronous transfer mode (ATM) adapters, and ADSL.
  • Infrared Data Association (IrDA) network devices must support Fast IR (FIR) and Serial IR (SIR).


Printers and Digital Still Imaging

The following requirements are introduced in PC 2001 System Design Guide.

  • Printers must have a USB interface, an IEEE 1394 interface, or a network interface port, but are permitted to have a supplemental legacy connection, such as serial or IEEE 1284.
  • Color matching requirements for digital imaging devices and printers include standard red-green-blue (sRGB) output and new Delta E tolerance requirements.
  • A printer driver must not run in kernel mode.
  • Still image device drivers must be implemented under Windows Image Acquisition (WIA) driver architecture.
  • USB camera requirements are defined, including support for the USB Still Image Device Definition Specification and Photographic and Imaging Manufacturers Association (PIMA) protocols in PIMA 15740.
  • Each printer and still image device must support sRGB output or have an ICC profile.

The following requirements are modified slightly or are unchanged from PC 99 System Design Guide:

  • Printer and driver supports Default Device Class Power Management Reference Specification, Version 1.0.
  • Still image devices must use USB, IEEE 1394, or SCSI (for scanners).
  • Digital still cameras must meet throughput requirements, based on the type of connection.


Part 1 Initiatives

Chapter 2 Easy PC Initiative

This chapter describes goals for the Easy PC Initiative and features that can be implemented to achieve these goals. The emphasis is on designs for consumer desktop systems, but most of the guidelines apply to mobile systems. Designers should use their judgment to implement the spirit of these recommendations, where applicable, for their specific system types. Some features build on the PC 2001 requirements; others indicate ways to add value beyond them. These recommendations are not PC 2001 requirements, except where citations point to specific requirements defined in Parts 2 and 3 of this design guide.


Easy PC Initiative Goals in 2000–2001

The Easy PC industry initiative, jointly announced by Intel and Microsoft in 1999, describes a shared vision for making the PC platform simpler, especially for new users, in order to grow the market and increase customer satisfaction.

The key goal for the Easy PC Initiative is to produce new PC designs that are easy to set up, easy to use, easy to expand, and easy to maintain. The Easy PC Initiative offers many recommendations for innovative system designs, architectural advances, and simple configurations that enable end users to benefit from new, exciting PCs that are reliable and easy to use. The industry will benefit from reduced support costs by removing configuration problems.

For additional information about the Easy PC Initiative and legacy-free design, see these Web sites:

  • http://developer.intel.com/technology/easeofuse/
  • http://www.microsoft.com/hwdev/newpc/

Easy to Set Up

Usability tests have found that the setup process for a new PC confuses first-time and nontechnical users. A goal for the Easy PC Initiative is to get the user from "PC in carton" to "PC in use" successfully and quickly. The out-of-box experience (OOBE) should be an easy, fast, and friendly experience that enables a novice user to set up a new Windows-based PC and begin using it without any outside assistance.

The Easy PC Initiative encourages the system manufacturer to completely preconfigure applications, connectivity, and other activities that have been shown to confuse first-time and nontechnical users. System builders are strongly encouraged to take advantage of Microsoft-provided tools for use with Windows operating systems to create streamlined installation routines, including integrated Internet signup and single-stop registration. The manufacturer can also customize and preconfigure dial-up connectivity.

Another goal for the Easy PC Initiative is to encourage system designers’ efforts to introduce new, innovative industrial designs, including designs with smaller footprints. By limiting internal expansion to manufacturing customization, system designers can pursue alternative design options that deliver the benefits of higher functional integration.

For specific examples, see "Easy to Set Up Guidelines" later in this chapter.

Easy to Use

The PC is a powerful and sophisticated device that can be daunting to new users. A goal for the Easy PC Initiative is to maintain the PC’s power and flexibility, while presenting the user with simple, intuitive access to system capabilities.

Beginning with the first display of the Windows desktop after the user completes the OOBE process, the hardware and software must immediately be usable. Common activities should be easy to find. Menu selections and desktop contents should be simple to avoid confusing the user. Messages and instructions should use nontechnical terms.

To make the PC more robust and reliable, the system designer should remove legacy hardware and software that are known to cause problems for users. Power management features should be fast and reliable. Networking should be automated. Configuration of preinstalled hardware and software helps ensure that the user has no reason to reboot the PC between sessions.

For specific examples, see "Easy to Use Guidelines" later in this chapter. See also Chapter 3, "PC System," for PC 2001 requirements that support this goal.

Easy to Expand

The PC is known for flexibility that allows expansion of its hardware, software, and networking capabilities. A goal for the Easy PC Initiative is to make it easy to add new features to the PC without compromising prior functionality. Expansion is provided using external, hot-pluggable connections such as USB, so the user does not have to open the PC case or shut down the system to add new capabilities. Where possible, the PC should be designed and preconfigured for anticipated expansion.

Another goal of the Easy PC Initiative is to encourage the home PC user to have ready access to high-speed communications and the Internet in the home. The system designer should integrate home networking connections. The system designer should also provide easy expansion for broadband technologies such as DSL and cable modems.

For specific examples that make it easier to set up a new PC and later to expand the PC’s capabilities, see "Easy Expansion Guidelines " later in this chapter. See also Chapter 14, "Network Communications," for PC 2001 requirements that support this goal.

Easy to Maintain

PC users find system maintenance is a chore. A goal for the Easy PC Initiative is to encourage integrated, robust system designs that allow the system to automatically maintain and protect itself from problems that could be introduced over time. Maintenance problems can be introduced in many ways, including BIOS updates, driver updates, and viruses. The system designer should provide well-integrated backup, update, and virus protection capabilities that reliably update and protect the user’s system.

In support of this goal, Microsoft has introduced capabilities in Windows Me and Windows 2000 that protect system files and allow easy restoration of system configuration. Microsoft supports automated driver and service updates through the Windows Update and Web-based technical support through the Microsoft PC Health Initiative.

For specific examples of ways to make PC maintenance easier, see "Easy to Maintain Guidelines" later in this chapter.


Legacy Removal and Easy PC Goals

Specific requirements for legacy removal are provided in Chapter 3 of the PC 2001 guide. This section explains the relationship of legacy removal to the Easy PC Initiative.

With the evolution of PC architecture, newer interfaces and approaches provide improved methods to integrate components and devices. "Legacy" components become candidates for obsolescence when new technologies reach appropriate cost points and functionality to benefit both users and the PC industry. Removing legacy components offers the opportunity to simplify the Windows-based platform, thereby enabling a more robust, easier-to-use system and allowing PC designers to reduce costs of both manufacturing and support. Users with the fewest existing dependencies on legacy components will be the earliest to adopt the new technologies.

From the PC manufacturer’s perspective, achieving lower costs is crucial, and removing legacy connectors and controllers translates into lower product cost. Simplifying the interfaces behind which devices are added and removed from the PC also translates into reduced support cost.

From the user’s perspective, newer interfaces such as USB provide greater flexibility, dramatically reducing configuration problems and the need for manual intervention or system reboots. Consequently, the user can add and use a greater number of device types based on a lesser variety of interfaces.

Of course, to encourage simple, dynamic capabilities to add and remove devices, removal of legacy interfaces must be accompanied by correct implementation of the newer interfaces. Therefore, achieving Easy PC goals means complying with the hardware, BIOS, and driver requirements as defined in the PC 2001 guidelines.

Performance improvement should be considered a secondary motivator for legacy input/output (I/O) removal. Many devices such as storage, graphics, and audio have already migrated onto the faster PCI and Accelerated Graphics Port (AGP) interfaces. As a consequence, end users might perceive only slight benefits to system performance. However, implementing devices on new buses can eliminate the performance drag of polling across legacy COM and LPT ports. Boot speed should also increase in systems that replace legacy code paths with new, properly designed architectures.

Chapter 3, "PC System," contains specific PC 2001 requirements for legacy-reduced and legacy-free systems.


Recommendations for Easy PC Configuration

This section recommends original equipment manufacturer (OEM) guidelines for system configuration to meet the goals of the Easy PC Initiative, with references to specific PC 2001 requirements that are related to some features in this chapter.


Easy to Set Up Guidelines

These "Easy to Set Up" guidelines define improvements to the OOBE process. The goal is to make setting up and using a PC for the first time as easy, fast, and friendly as using any common, sophisticated consumer electronics device.

These guidelines result from usability tests that show experienced users take at least 30 minutes to set up a PC, and novice users take at least an hour and often need assistance at least once to complete the entire setup process.

All users should be able to set up a new PC system in less than 15 minutes without any outside assistance.

Innovative Form Factors

Instead of beige boxes, the OEM offers new innovative industrial designs that use an appealing consumer-oriented design language.

Packaging Guidelines

These guidelines help users to easily assemble the physical components of the PC system.

Boxes labeled with contents. The OEM clearly labels every OEM-supplied box with an icon or text describing what it contains: monitor, keyboard, main unit, and so on. In addition, all the boxes are numbered to indicate the order in which they need to be opened, and the box labeled Number 1 contains the setup map for the system.

Easy-to-follow pictorial setup instructions. The OEM provides a setup map with the PC that is placed in the package so that it is immediately visible when the user opens the box labeled Number 1. This setup map is simple enough that users with no prior computer experience can understand the instructions:

  • It provides simple, step-by-step instructions, with illustrations describing how to set up the PC and any peripherals provided with the system.
  • It shows the colors and icons for the cables and connectors so the user can easily match them. Color and icon recommendations are available on the PC Design Guide Web site listed in Appendix D, "Master Reference List."
  • It matches the pictures and text with the box numbers, appearance, and procedures for the specific PC model and does not include information about any other physical design.
  • It provides instructions on how to use the on/off and sleep buttons.
  • It includes the OEM’s technical support telephone number.

The OEM may also provide a separate video that shows the complete setup process from opening the boxes to the final Windows OOBE process and connecting to the Internet.

Easy to remove from packaging. The OEM provides a mechanism to assist with easy removal of the main unit and monitor from packaging. This assistance can include, but is not limited to, handles and straps, located on the unit or in the packaging, to facilitate removal from packaging.

For monitors and other heavy components that typically are tightly bound in foam packing, the OEM should provide mechanisms that help the user to remove these objects from their boxes, such as handles or the ability to slide systems and components out of the box. Also, the OEM should provide the user with an immediately visible explanation of how to easily unpack and move the component.

Simple cabling systems. For cables that connect peripherals to the main unit, no more than two cables, maximum, are needed for Web connectivity and home networking. For example, no additional external cable connects the home-networking card to the network adapter or modem.

If the system provides a built-in V.90 modem, DSL, and a HomePNA solution, the system has no more than two RJ-11 jacks with equivalent wiring.

Some possibilities to simplify cabling include:

  • Use a single cable for the keyboard and to connect the mouse to the keyboard.
  • Use a radio frequency (RF) wireless keyboard and mouse.
  • If the monitor has a USB hub, integrated speakers, or both, provide a single cable for all connections other than power.
  • Provide cables of the appropriate length. If that length cannot be determined, consider retraction mechanisms for long cables or extension cables for short cables.

USB keyboard port on PC has an icon. If the PC does not have an integrated keyboard, the PC has a USB port designated for the USB keyboard. This designation encourages users to attach the keyboard close to the system root hub, which helps reduce boot and resume times, thus improving system boot performance. To help guide users to this enhanced configuration, OEMs can label the appropriate port with an icon, include the labeled port on the setup map, and recommend that users plug the keyboard directly into this designated port. For recommendations about icon implementation, see the Icons for PCs Web page, listed in Appendix D.

Easy-to-access connectors. At a minimum, two high-power USB ports should be easily accessible to the desktop user—that is, placed on the front or side of the main unit, keyboard, or monitor. For mobile users, at least one high-power USB port should be available, and it can be located on the back of the machine. The goal for this guideline is to make connectors for hot-pluggable peripherals conveniently accessible to the user.

See SYS–0021, "PC 2001 system includes USB with two user-accessible USB ports, minimum," in Chapter 3.

Streamline OOBE process. To help users complete system setup as quickly and painlessly as possible, manufacturers should make the setup process straightforward. This streamlining includes:

  • Making sure all system setup occurs within the Windows OOBE process. Do not include subsequent setup programs or steps after the user goes through the initial setup process.
  • Prepopulation of user information during OOBE. The goal is to provide the quickest time and least confusion for users to get to the Windows desktop. To achieve this goal, manufacturers set various parts of the registration information for users before they get their machines. For retail systems, OEMs should consider ways to allow easy population of user information at the store or purchase location, as well as prepopulating any regional information supported in their manufacturing processes.
  • Consolidated entry of user information. Provide only a single registration, instead of asking the user multiple times for the same data.
  • No reboots during the OOBE process. The system does not include any custom components that require reboot during the OOBE process.
  • No executable software is downloaded during the OOBE process. No executable software downloads occur during the Windows OOBE process. All required software and options that the user can select are preinstalled on the system itself.
  • Minimize the number of internet service provider (ISP) offers presented to users. Provide the user with clear choices on ISP offers by presenting and clearly describing a minimum number of ISP offers.
  • Enable hardware check. Manufacturers should enable hardware diagnostic checks that determine whether components are functioning properly. Here are a few examples. The keyboard and mouse are plugged in (if USB), and the speakers are working. If a phone-line dial-up connection is to be used, a dial tone exists. On-screen troubleshooting help includes support contact information.


Easy to Use Guidelines

These "Easy to Use" guidelines define improvements that encourage immediate access to the common tasks for which the user bought the PC, with seamless system support for attaching and detaching network connections and peripherals at any time.

Ease of Use Software Interface Guidelines

These guidelines provide a foundation for an easy-to-use, attractive system.

Usability testing shows that the proliferation of choices provided by Microsoft and the OEM on the Windows Desktop can confuse and frustrate the user. The following recommended characteristics present users with a simple user interface that directs them to the actions they will most likely choose.

Minimize the number of preinstalled icons in the System Tray. To minimize the overhead associated with System Tray resident programs, and to avoid confusing the user, the System Tray should contain only the following permanent icons: an anti-virus icon, the Task Scheduler, a technical support icon, and any locale-specific utilities such as specific language input mechanisms. The System Tray can also contain transitional icons that appear only when the system performs certain functions, such as printing, mail delivery, or battery/AC.

Minimize desktop, quick launch, and Start menu icons. Usability studies show that novice and typical users get confused and overwhelmed by too many choices and options with their computer. To reduce confusion, OEMs should minimize the number of choices and icons that users are exposed to when first logging on.

All software is preinstalled. All software provided with the system is preinstalled, instead of simply included on the system for the user to install later. As an alternative, the OEM can provide software with easy installation mechanisms, such as using auto-run or integrating with Add/Remove programs.

Hard disk configured for easy use. Whenever not constrained by specific applications, the hard disk should be configured to display to the user no more than one visible drive letter per physical drive. The capacity of the disk, as advertised, is the available capacity for the end user, as reported by the operating system. Both guidelines apply whether the hard disk is built into the system or offered as an add-on product.

The hard disk is formatted with FAT 32 or Windows NT® file system (NTFS) to provide the best capacity and to gain the related benefits of a single file system with a single drive letter per volume.

Web-based support and product offerings. The OEM presents information on a Web site to provide the following:

  • Support information. This OEM support is provided using Windows PC Health or a similar OEM-defined mechanism.
  • Software and hardware offerings that have been designed and tested for compatibility with the system.
  • A link to Windows Update at http://windowsupdate.microsoft.com.
  • Offerings for the following classes of external expansion devices: digital cameras, HomePNA adapters, printers, scanners, hard drives, 10base-T network adapters, DVD ROM if one is not included with system, and backup mechanisms implemented in hardware and software.

OEM help topics integrated with or linked to Windows help. OEM help topics are integrated or linked to the Windows Integrated Help Center. At a minimum, these help topics include:

  • How to install and uninstall system-specific hardware and software. In particular, the help file explains how to expand system capabilities using USB and whatever other expansion capabilities that are provided on the system.
  • How to maintain the physical unit, such as how to clean the mouse
  • How to establish a network connection for the specific system
  • A list of specific system components for which the OEM supports upgrades

All timed product offerings and schedules configured with the System Task Scheduler. Only Task Scheduler is configured to display automatic product and service offerings to the user. Each offering provides the user with the opportunity to cancel future notifications.

Nontechnical terms in messages and documentation. All messages configured by the OEM use nontechnical terms that assume no prior PC experience.


Ease of Use User Interface Hardware Guidelines

These guidelines define hardware mechanisms that help ensure that the user is presented with simple choices for common actions.

Internet and e-mail buttons in hardware. The system includes the following HID-compliant quick-launch buttons on the monitor, the keyboard, or another location where users can easily push a button for common tasks:

  • Internet (or Home), launching the user’s default browser
  • E-mail, launching the user’s default e-mail as specified in Internet options

Quick-launch buttons do not override any user-defined options.

All volume controls on the system are HID compliant. A volume control should be on the keyboard or some location that is easily accessible to the user. Volume controls use HID interfaces to stay synchronized with each other. Any analog volume or power controls on powered speakers are located behind the speaker units or otherwise out of the user’s immediate view. USB HID-capable speakers do not have analog or power control.

For PC 2001 support of this feature, see AUD–0335, "USB audio meets USB specifications" in Chapter 11.

Availability of easy expansion mechanisms for network adapters. Home networking and broadband solutions are preinstalled or the components are offered by the OEM as an easy "no touch" upgrade. "No touch" upgrade means:

  • The upgrade does not require opening the PC case to add components.
  • The hardware is hot-pluggable, using an external expansion connection.
  • The solution uses the existing home infrastructure for connectivity.
  • All drivers for solutions available when the system ships are preinstalled on the system.
  • If the system includes built-in home networking capabilities, the home networking solution is HomePNA.
  • If the system can be configured as an Internet gateway, it should support wake on LAN capabilities for waking the system from S3 state.
  • If the system is provided to the end user with built-in home networking and broadband, the user must be able to use both at the same time.


Appliance-like Operation Guidelines

Microsoft Windows operating systems have boot performance enhancements to speed the time from turning on or resuming the power until the user can begin working. The features in this section supplement these boot performance enhancements to help ensure that the PC is ready to use quickly, in the same way that consumer appliances are "instantly available."

Fast system start-up. The PC system should correctly implement PC 2001 power management requirements and minimize start time for cold boot, resume from hibernate, and resume from suspend. Fast start-up can be optimized through the following performance enhancements:

  • Reduced POST time
  • Decreased hard-disk spin-up time, which is not dependent on BIOS and begins as soon as power is applied
  • Minimized number of applications and utilities loaded during start-up
  • Shortened load time for drivers and memory-resident utilities, including System Tray

Maximize system resources available after boot. The Resource Meter can measure resident memory items.

Silent sleep and low noise during system operation. The goal for minimum system noise should be:

  • No noise during any supported sleep state. The system can periodically turn on the fan during a sleep mode to maintain a thermal envelope.
  • Fan noise does not exceed 37 dB A-weighted, measured with sound pressure at user position during normal operation.

In Chapter 3, see SYS–0003, "Hardware design supports OnNow and Instantly Available PC initiatives," for PC 2001 noise requirements that support this goal.


Power Button Guidelines

Current PC designs often present multiple "power button" choices. Usability research shows significant customer confusion about what each button actually does and the reasons to push various buttons. Usability testing also shows that some users mistake the monitor power button as the universal power button for both the PC and the monitor.

These guidelines address issues that users have with the power control interface.

One ACPI-compliant on/off button on the main unit. The system includes a single on/off button on the main unit that meets the guidelines defined for the power button in ACPI 1.0b and PC 2001 System Design Guide.

The on/off button on the main system unit is configured to place the system in the S4 (hibernate) state, rather than in the S5 (off) state. The main unit has no sleep button. The on/off button has an indicator light associated with it, either in the button itself or adjacent to it.

If the main unit includes a separate physical hard power switch (as required in some locales), it is placed on the back of the unit.

The on/off button should be located away from any media-eject buttons to prevent user confusion or accidental actions.

See SYS–0003.3, "System provides software-controlled, ACPI-based power switch," in Chapter 3, for applicable PC 2001 ACPI requirements.

Nonintegrated keyboard includes a sleep/wake button. A sleep button is located on the keyboard and is configured to place the system in the S1 or S3 sleep state or to wake the system from sleep. At a minimum, the button is labeled with a sleep icon.

Hardware indicator changes appearance to show the power state. One or more visual indicators on the main unit show whether the system is in the working, sleep, or hibernate (off) state. The indicator remains lit but changes color when the system is in the sleep state; when the system is in a hibernate or off state, the indicator light is off.

See SYS–0003.2, "System provides one or more indicators to show whether the system is in the working or sleep state" in Chapter 3, for PC 2001 power state indicator requirements.

User instructions for controlling system power. The goal is to educate users on orderly system shutdown. The OEM provides the user with clear directions for using the on/off and sleep buttons. The instructions clearly indicate that these buttons are the power controls, and they specifically instruct users never to shut off the system from a power strip control.


Easy Expansion Guidelines

These "Easy Expansion" guidelines define improvements that help the user to easily add peripherals and software to the system.

Basic Expansion of Hardware and Driver Guidelines

Following these guidelines helps to provide a trouble-free experience during system expansion.

Legacy-free design. The system meets the criteria for legacy-free design, as defined in PC 2001 System Design Guide. For specific details of this system design criteria, see "PC 2001 Legacy-Free System Requirements" and design notes in "PC System References" both in Chapter 3.

No user access to internal parts. All user-accessible expansion capabilities are external. User-accessible memory expansion is discouraged in the same manner.

The system can have internal PCI, AGP, or memory slots to allow the manufacturer in the factory or the distributor to configure the system. However, these slots should not have quick-access mechanisms, and they should not be promoted as end-user expandable. If internal expansion or memory expansion is available, dealer or manufacturer service is available to perform the expansion.

Two or more high-power USB ports available for expansion. A desktop system has two high-power USB ports that are free after the keyboard, mouse, communications, and networking devices are connected to the system. Mobile systems should have at least one free high-power USB port.

For PC 2001 guidelines that support this feature, see SYS–0021, "PC 2001 system includes USB with two user-accessible USB ports, minimum" in Chapter 3.

USB 2.0 or IEEE 1394 port. The system includes USB 2.0, IEEE 1394, or both to support external high-speed peripherals for video, mass storage, and backup.

Only hot-pluggable external connectors. All external digital and analog connectors, with the exception of the VGA connector, completely support hot plugging and removal while the PC is running.

Color-coded connectors with icons. For the PC system itself, and for all peripherals included with the system or offered by the OEM, the connectors or the overlay around connectors implement the icon and color-coding schemes that are provided on the Icons for PCs Web page listed in Appendix D, "Master Reference List." The icon also appears on the shroud for the device connector, and the icons match between the main unit and connector shroud. Mobile units can choose not to include color coding for aesthetic reasons and can wrap icons underneath the unit, if there are space-constraint issues. Multiple audio jacks are all color-coded if they are provided and adjacent to each other. Speaker, microphone, and line-out jacks are color-coded and use standard icons. The headphone jack does not need to be color-coded if it is not on the back of unit, but the jack does need to use the industry-standard headphone jack icon. Headphone jacks located on CD or DVD drives do not need to use icons or color coding.

Easy access to drivers for all hardware components. For easy future installation of hardware components, the OEM provides drivers that are easily accessible to end users. Locations for these drivers should include:

  • Recovery CD
  • OEM Web site
  • Windows Update Web site

INF files prepopulated for all devices offered. Entries for all OEM-offered devices are prepopulated in the INF files preinstalled on the system. This guideline includes entries for all keyboards in Keyboard.inf, all mice in Msmouse.inf, and other pointing-device INFs.


Guidelines for OEM-Offered Components

These guidelines apply to additional drivers, utilities, and application software offered by OEMs.

Software and hardware components do not require system reboots. The OEM should not offer hardware or software components that require the system to be rebooted during installation or configuration. Reboots are allowed for networking-related hardware and software components.

Only Win32®-based software and utilities ship with system. All software updates and additional utilities offered by the OEM through any distribution mechanism are Win32-based software. The software does not require
MS-DOS–based decompression or installers. This restriction does not apply to OEM diagnostic utilities or the emergency recovery software provided with the system.

For applicable PC 2001 guidelines, see SYS–0042, "Preinstalled components and upgrades do not require MS-DOS or legacy interfaces," in Chapter 3.

Peripheral devices that are offered follow PC 2001 general device requirements. All peripheral devices offered as additional products meet the requirements in "PC 2001 General Device Requirements" in Chapter 3.

Offered software follows Windows-based application guidelines. All software that is preinstalled or offered to users—including utilities and components included with hardware peripherals—follows the guidelines that apply for the Windows 98 operating system, as defined in Application Specification for Microsoft Windows 2000, for desktop applications, Version 1.0a or later, listed in Appendix D.

Offered software does not interfere with other installation. Preinstalled software or software offered to the user by the manufacturer, such as anti-virus or compression programs, does not interfere with installation of new hardware or software.


Easy to Maintain Guidelines

These "Easy to Maintain" guidelines define improvements to ensure that system functionality and performance are maintained over time.

Basic Maintenance Guidelines

These guidelines encourage protection of key system functionality.

System File Protection enabled. The Windows System File Protection feature is enabled by default when the system is delivered to the user.

System Restore capabilities enabled. The Windows System Restore feature or a similar third-party restore mechanism is enabled by default when the system is delivered to the user.

Automated maintenance preconfigured. The OEM uses Windows Task Scheduler to automatically configure maintenance activities. The following maintenance services are preconfigured to run automatically, using defaults as shipped in the operating system:

  • Disk cleanup—remove temp files and so on. Disk cleanup is configured by default not to empty the recycle bin.
  • ScanDisk, disk defragmentation, and Auto-update.

Optionally, Backup can be scheduled to run automatically.

Easy System Update Guidelines

These guidelines support improved update functionality.

Automatic critical update notification enabled. The OEM enables automatic critical update notification and installation, using Windows Update or the OEM’s update site to deliver both notification and installation.

Self-extracting critical fixes provided. Critical fixes to system components are provided as self-extracting, self-installing executables and are installed as automatic updates.


Part 2 Platform Requirements

Chapter 3 PC System

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter summarizes the basic features required for all PC 2001 systems.

For definitions of common terms, acronyms, and abbreviations used in this guide, see the glossary; see also "Terms and Conventions Used" in "About the Design Guide."


PC 2001 General System Requirements

This section presents a summary of the general system requirements, including system board, memory, and power management requirements. For performance requirements and exceptions for workstation and mobile PCs, see Chapter 4, "Workstations," and Chapter 5, "Mobile."

Note: Mobile PC exceptions are found throughout this guide.

SYS–0001. System performance meets PC 2001 minimum requirements

The performance requirements for PC 2001 systems are based on the minimum computational capabilities and performance necessary to support the demands of Windows-based applications together with the estimated processing demand and processing capability of the lowest-end processor in mid-2001.

The minimum performance requirement consists of the following.

  • SYS–0001.1. System includes CPU and cache that meets PC 2001 minimum requirements. The minimum microprocessor capability is specified to support the demands of rich media, Internet access, and conferencing. The performance requirement for these media enhancements is specified so that the system meets performance targets at minimum platform power.

The processor requirements for PC 2001 desktop systems are:

  • Minimum 667 MHz processor
  • Minimum 128 KB of cache present and enabled
  • SYS–0001.2. System memory meets PC 2001 minimum requirements. A PC 2001 system must meet the following memory requirements:
  • 64 MB RAM minimum
  • 128 MB RAM minimum for computers that have Windows 2000 preinstalled
  • SYS–0054. If implemented, system memory includes ECC memory protection. If error correction code (ECC) is implemented, system memory and external processor cache must be protected with ECC memory protection. All ECC RAM visible to the operating system must be cacheable. The ECC memory subsystem hardware must be able to detect at least a double-bit error in one word and to correct a single-bit error in one word, where word means the width in bits of the memory subsystem. A detected error that cannot be corrected must result in a system fault.
  • SYS–0001.3. APIC implemented and properly connected. All desktop systems must be Advanced Programmable Interrupt Controller (APIC) enabled. This means:
  • The local APIC in the processor must be hardware enabled.
  • All hardware interrupts are connected to an input/output Advanced Programmable Interrupt Controller (IOAPIC).
  • The IOAPIC is connected to the local APIC in the processor. If an 8259 is present in the system, the system must be configured such that the 8259 interrupt controller functions correctly with an operating system that is not aware of the APIC.

The BIOS must program and enable the system 8259 Programmable Interrupt Controller (PIC) for PC-AT compatible mode operation. The BIOS must program the APICs for Virtual Wire Mode operation. There are two Virtual Wire modes available: Virtual Wire Mode via the Local APIC and Virtual Wire Mode via the IOAPIC. Virtual Wire Mode via the IOAPIC is the preferred method of operation to be programmed by the BIOS.

Mobile PC Note

Mobile systems that do not have an APIC present are excluded from this requirement.

SYS–0002. System design meets ACPI 1.0b specification and PC 2001 requirements

The system board and BIOS must support Advanced Configuration and Power Interface Specification, Revision 1.0b. This requirement permits the system to correctly support Plug and Play and power management.

ACPI support must include the following.

  • SYS–0002.1. System supports S3, S4, and S5 states. Desktop and single-processor workstation systems must support the S5 (soft-off) state as required in the ACPI 1.0b specification, plus the S3 and S4 states. Support for S1, S2, and S4BIOS is optional. Every system must support wake from all implemented sleep states, except S4 and S5, for all wake-capable devices and buses.

Multiprocessor systems are required to support S1, S4, and S5. Multiprocessor support for S3 is optional.

Mobile PC Note

Mobile PCs are required to support S1 or S3, in addition to S4 and S5. Mobile PCs are not required to wake from S3 or S4.

  • SYS–0002.3. System provides no user-accessible method for disabling ACPI in the BIOS. If the system includes a BIOS setting that the manufacturer can use to switch between ACPI and Advanced Power Management (APM) modes, this setting must not be exposed to the end user in a CMOS setting or other means once a Microsoft ACPI-enabled operating system has been installed. Disabling ACPI will cause boot failures, because Windows 2000 relies on it for identification and initialization of system devices. Not having a user-accessible option to disable ACPI support does not impact the ability to properly load an operating system that is not ACPI compatible.
  • SYS–0002.4. If software fan control is implemented, thermal design and fan control comply with ACPI 1.0b. A thermal model and fan control must be implemented as defined in Section 12 of the ACPI 1.0b specification as a means of running the PC quietly while it is working and of turning the fan off while it is sleeping. Notice that hardware override is permitted only to handle thermal conditions when the operating system is not running, the operating system has put the system in a sleep state, or safe operating parameters have been exceeded.
  • SYS–0002.5. All system-board power management or Plug and Play features comply with the ACPI 1.0b. This requirement applies even if a particular feature is not a specific requirement or recommendation in ACPI 1.0b.
SYS–0003. Hardware design supports OnNow and Instantly Available PC initiatives

The OnNow and Instantly Available PC initiatives are based on these goals for the user experience:

  • The user experiences the PC as off when it is in a sleep state.
  • The user can easily see whether the PC is working or sleeping.
  • The user can easily control power through switches and software.

These initiatives are described in the Instantly Available Power Managed Desktop PC Design Guide. OnNow initiative information is available on the OnNow and Power Management Web site. Both are listed in "PC System References."

The following items are required to support these initiatives.

  • SYS–0003.1. System and devices appear as off in the sleep state. At a minimum, all media drives, display, sound, input devices, and fans must be perceived as off when the system has completed the transition to a sleep state, for example, no noise or lights other than the status indicator. It is acceptable for system fans to run for some period of time, provided these automatically turn off once sufficient cooling is achieved.
  • SYS–0003.2. System provides one or more indicators to show whether the system is in the working or sleep state. System provides a unique indication for the working state (S0), the sleep states (S1, S2, and S3) and off (S5) system state.

S4 must appear to the user as the off state (S5); therefore, S4 and S5 must have the same indication.

Each indication must visible and unique.

  • SYS–0003.3. System provides software-controlled, ACPI-based power switch. The system must provide an easily accessible power switch that can be controlled by software. This requirement for an easily-accessible power switch does not preclude power-control capabilities, such as closing the lid on a mobile PC.

The following are requirements for power/sleep buttons:

  • The function of these buttons is determined by the operating system.
  • In case of a hardware or software failure that prevents normal operation of the software-controlled buttons, the switch capabilities must include an override mechanism for turning off the PC.

A four-second override mechanism is recommended in Section 4.7.2.2.1 of the ACPI 1.0b specification. The override must be associated with the user’s primary switch interface, in order to establish an industry-standard implementation.

Notice that the override mechanism is not an alternative way for the user to turn off the PC in normal operation; it is only a fail-safe function for fault conditions.

  • If the power/sleep button is provided on the keyboard, the key must be clearly labeled and must consist of a single keystroke for turning on the PC, to provide accessibility for persons with disabilities. (Two keystrokes can be used to turn off the PC.) For information about scan codes for keyboard power switches, see the information listed in "PC System References."

The following are implementation requirements for the power/sleep button:

  • A single-button design is preferred. This button must be the user’s primary switch interface, and must be a power button as defined by the ACPI 1.0b specification.
  • If a two-button design is used, the sleep button must be the user’s primary switch interface, and be easily distinguishable from the power button. The preferred implementation in a two-button design is to hide the power button behind a door or on the rear of the system.
  • SYS–0003.4. Each device and bus supports the power management specifications for its class. All devices and drivers must support the D0 and D3 power states consistent with the definitions in the relevant device class power management reference specification and the Default Device Class Power Management Reference Specification, Version 1.0 or later. Support of D1 and D2 states is optional, unless required in the relevant device class specification. Requirements referring to D3 assume that power is removed unless otherwise noted.

Each device can successfully survive a system sleep/wake transition (where the device transitions from D0 to D3 to D0) without losing functionality and without requiring user intervention to restore functionality.

This requirement includes no requirement to retain any device context because it will be preserved or restored by the driver when returning to the D0 power state.

PCI, USB, IEEE 1394, and PC Card buses must support power management requirements as defined in their related bus standards. For information on PCI, USB and IEEE 1394, see Chapter 6, "Buses and Interfaces." For information on PC Card, see PC Card and CardBus Guidelines, Version 1.1 .

  • SYS–0003.5. System power supply provides standby power for system wakeup events. The system supplies adequate standby power to support wakeup events. At a minimum, the system must provide power for the core chipset, including memory and all integrated wake devices, for wakeup from the keyboard, a pointing device, and a single network device such as a LAN or wide area network (WAN) adapter connected via an external bus or open PCI slot when the system is in the ACPI S3 state. This requirement applies for S4 if the system supports wake from the ACPI S4 state.

IEEE 1394 host interface does not have to provide standby power for system wakeup events.

For more information, see the Instantly Available PC System Power Delivery Requirements and Recommendations, listed in "PC System References."

Mobile PC Note

This requirement for the system power supply does not apply to mobile PCs.


PC 2001 BIOS Requirements

This section states requirements for the BIOS. Remote boot is separate from general BIOS requirements to distinguish between other desktop or mobile computers.

For BIOS requirements related to legacy-free designs, see "PC 2001 Legacy Free Requirements."

BIOS–0004. BIOS meets PC 2001 requirements for OnNow and Instantly Available PC support

The intention of this requirement is to avoid presenting the end user with confusing information and unnecessary visual display, and to permit access to error information by using a hot key.

ACPI BIOS entries, as defined in Section 1.6 of the ACPI 1.0b specification, must be the same for supporting either Windows Me or Windows 2000.

The following BIOS capabilities are required for OnNow support.

  • BIOS–0004.1. BIOS supports Fast POST (S4, S5, or mechanical off). Power on to the bootstrap loader handoff must occur in 12 seconds or less for systems not using SCSI as the primary storage connection. This time limit includes, if present, initialization of keyboard, graphics adapter, and a parallel ATA storage bus. For systems containing additional option ROMs, system integrity and security services, or user PXE boot option, an additional 4 seconds are allowed per instance. This time limit does not include hard disk spin-up time, time used for loading CPU firmware, multiprocessor systems, and time required for ECC scrubbing, if supported and enabled.
  • BIOS–0004.2. Resume from sleep state (S1–S3) to operating system handoff occurs within 1 second. This requirement does not apply for the S4 state. For sleep states S1, S2, and S3, the time to operating system handoff is measured from when the processor starts running (first instruction) to the time that the BIOS jumps to the Waking Vector in the Firmware ACPI Control Structure table, as described in Section 5.2.6 in the ACPI 1.0b specification.
BIOS–0005. BIOS includes local boot support

The BIOS boot support requirements include the following. Additional BIOS requirements to support legacy reduction are defined in "PC 2001 Legacy Reduction Requirements." For information about BIOS and ATA, see ATA–0119, "Controller supports Ultra DMA (ATA/33)," in Chapter 6.

  • BIOS–0005.1. BIOS supports booting the system from CD or DVD. The system BIOS or option ROM must support the No Emulation mode in "El Torito"—Bootable CD-ROM Format Specification, Version 1.0, by IBM and Phoenix Technologies, Limited, for installing Windows from optical media, such as bootable CD media.

The primary optical device must be bootable. This requirement applies to the primary optical storage provided and on the primary bus that the device is attached, in its shipping configuration.

  • BIOS–0005.2. BIOS provides boot support for USB keyboards and hubs. This BIOS support, as defined in Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1, with particular attention to the Keyboard Boot Protocol, must provide the ability for the user to enter the BIOS setup utility and also provide enough functionality to install and boot an operating system that recognizes USB peripherals. USB keyboards built as stand-alone devices, part of a composite device, or part of a compound device must all be recognized and usable. The BIOS is required to support keyboards behind at least two levels of external hubs.

For systems with multiple USB host controllers, BIOS support for USB keyboards and hubs is required for all host controllers that are integrated on the system board (that is, not add-on cards).

Keyboard and pointing devices must be functional for all modes of the operating system, including booting, loading, safe mode, and operating system setup and installation.

USB external connectors and USB input device support must be enabled by default in the BIOS, and the BIOS must make USB input devices, such as keyboards and pointing devices, available at boot time.

  • BIOS–0005.3. BIOS handles long descriptors read from USB device attached at boot time. When a USB host requests the configuration descriptor for a device, the device returns the configuration descriptor, all interface descriptors, and endpoint descriptors for all interfaces in a single request (see section 9.4.3 of the USB 1.1 specification). The maximum size of the returned data is 64 KB.

To enumerate the USB and configure boot devices, the BIOS must make a configuration request to every device encountered. Therefore, the BIOS must be capable of handling a maximum length descriptor if such a descriptor is returned. However, the BIOS is required to configure only boot devices. Nonboot devices can be left in the addressed USB-visible device state.

  • BIOS–0005.4. Operating system recognizes the boot drive in a multiple-drive system. The BIOS must comply with the implementation of boot-drive determination in multiple-drive systems as defined in Section 5.0 of the BIOS Boot Specification, Version 1.01. Both Windows Me and Windows 2000 operating systems use this format for determining the boot drive when new bootable devices are introduced to a PC.
  • BIOS–0005.5. System timer is supported at system boot. The ROM BIOS must make sure that the timer is on at system boot and that timer interrupts are occurring as part of power-on self-test (POST) or reset.
BIOS–0006. BIOS supports SMBIOS 2.3

Windows 2000 can present system management BIOS (SMBIOS) 2.2 or later static table data in Windows Management Instrumentation (WMI). System designers must provide platform-specific static information at boot time using this mechanism. For more information, see System Management BIOS Reference Specification, Version 2.3.

BIOS–0007. BIOS and CMOS properly accommodate dates

BIOS and CMOS firmware support calendar dates from January 1, 1999 through December 31, 2099.

BIOS–0008. BIOS supports security

All PC systems must provide some mechanism for security, such as a preboot password, to protect enable/disable capabilities for hardware components before the operating system boots.

BIOS–0009. BIOS supports BIOS updates and revisions

Capability for BIOS updates must be provided. The following methods can be used to meet this requirement:

  • Through a remote new system setup mechanism downloaded and executed at boot time as described in NET–0256, "Adapter can be used as a boot device" in Chapter 14.
  • Through normal file access and execution methods when the system is fully booted into the normal operating system environment.

If option ROMs are provided, they must also be capable of being upgraded.

BIOS–0010. System BIOS supports debug port

BIOS provides support for system debug port. The debug port can be used during system startup for debugging, troubleshooting, and software development.

If a legacy serial port is implemented, the BIOS must provide an option to configure at least one legacy serial port to use either 2F8h or 3F8h. This capability allows the port to be treated as a boot device by the BIOS and is required to be usable by components as a diagnostic port in the event that system debugging is required by either the BIOS or the operating system.

For a legacy-free system, the implementation must meet the requirements defined in requirement BIOS–0015, "BIOS supports ACPI legacy-free reporting mechanism," and SYS–0046, "System supports legacy-free debug capabilities."

The Debug Port Specification is available at on the Microsoft Web site listed in "PC System References."

BIOS–0011. System BIOS and option ROMs support Int 13h Extensions

BIOS and option ROMs support Int 13h Extensions as defined in the "Layered Block Device Drivers" section of the Windows 98 DDK. This requirement also applies for redundant array of inexpensive disks (RAID) controllers when implemented, to support booting from Int 13h Extension devices. For additional information about Int 13h Extension devices, see ATA–0117, "ATA controller supports Int 13h Extensions and Logical Block Addressing," and SCSI–0106, "Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions," in Chapter 6.

BIOS–0012. ROM BIOS interrupt handlers preserve values in all registers

ROM BIOS hardware interrupt handlers and system management interrupt (SMI) handlers must preserve the values in all registers, including the high 16-bits of 32-bit registers. ROM BIOS application programming interface (API) handlers must preserve the values in all registers, including the high 16-bits of 32-bit registers that the API is not documented to modify.

Any ROM BIOS API that is documented to modify only the low 16-bits of a 32-bit register must preserve the high 16-bits of that 32-bit register; when the bits are preserved there are less likely to be compatibility problems for applications that use that API.

If a ROM BIOS API is documented to modify the flags—for example, it is documented to return with the CARRY flag set or cleared—this restriction does not apply to individual arithmetic bits in the flags register. Any ROM BIOS API that is documented to modify the flags is assumed to modify all of the arithmetic flag bits: AUX-CARRY, CARRY, OVERFLOW, PARITY, and ZEROSIGN.

The values of the other bits in the flags register must be preserved unless the API is documented to modify them.

BIOS–0014. BIOS supports remote boot

Systems designed for use with Windows 2000 must meet these requirements.

Mobile PC Note

These requirements only apply to mobile PC systems that include either a system board LAN network interface or a preinstalled mini-PCI LAN adapter.

  • BIOS–0014.1. BIOS supports PXE. The system must support remote boot as defined in Preboot Execution Environment (PXE) Specification, Version 2.1.
  • BIOS–0014.2. BIOS supports booting the system from the network and using F12 to force a system boot. The system BIOS must comply with the requirements that apply to Plug and Play devices as defined in Sections 3 and 4 of the BIOS Boot Specification, Version 1.01. This specification describes the requirements for initial program load (IPL) devices.

Systems that do not have an F12 key or already use the F12 key for another OEM-defined BIOS function can use an alternate key for network boot.

  • BIOS–0014.2.1. BIOS allows boot devices to be configured in order of precedence for boot. This feature must be implemented in accordance with Appendix C of the BIOS Boot Specification, Version 1.01. This feature is a PC 2001 requirement, even though it is optional in the BIOS boot specification.
  • BIOS–0014.2.2. Interface clearly shows boot order when users make configuration choices. For example, in a system that permits booting from floppy disk drive, hard disk drive (HDD), CD drive, DVD drive, or network adapter, it must be clear to the end user how to set a boot order that favors a specific device, such as the network adapter.
  • BIOS–0014.2.3. F12 key forces a system boot initiated from the network adapter. This key function must be enabled by default. Configuration of this feature can be provided through a BIOS configuration setting. When this feature is enabled, the boot display must indicate that F12 will invoke a network boot. This display must appear for a duration sufficient to be read by users, but must not lengthen the overall time needed to boot the machine.
  • BIOS–0014.3. System UUID is provided in print. The system universal unique ID (UUID), in accordance with the Open Group’s Common Application Environment (CAE) Specification, must be provided to the user in printed form for assistance in environments where it might be used as part of prestaging systems. This printed form is left up to the system manufacturer, but suggested means include posting the UUID on the system chassis or case, or printing the ID on the shipping carton.
  • BIOS–0014.4. BIOS supports BIS. For systems that include integrity or authentication services for downloaded remote boot images, the BIOS must provide these capabilities as defined in Boot Integrity Services Application Programming Interface, Version 1.0.

Boot Integrity Services (BIS) requires inclusion of structure type 31 (the BIS Entry Point) in the table of exported SMBIOS structures, in addition to the management data required by SMBIOS 2.3. See BIOS–0006, "BIOS supports SMBIOS 2.3." The BIS Entry Point requires that both 16-bit real-mode and 32-bit flat protected-mode entry points are nonzero. The overall structure checksum evaluates to zero.

  • BIOS–0014.5. System BIOS provides remote lockout capability. During remote management of a PXE client, remote lockout is required to prevent an end user from interrupting sensitive operations like a BIOS update. The remote lockout interface (RLI) allows programmatic lockout of events that could interrupt such an operation. Software running on the client system uses the interface.

The RLI hides the details of the underlying hardware implementation. Thus, manufacturers can provide different lockout hardware implementations while providing a consistent control interface to system software.

For a full explanation of the RLI, see Appendix B, "Remote Lockout."

BIOS–0015. BIOS supports ACPI legacy-free reporting mechanism

Fixed ACPI Description Table (FADT) settings must be supported and correctly implemented, including support for reporting legacy-free and hard reset/boot capabilities. For more details, see the OnNow and Power Management Web page listed in "PC System References."

BIOS–0016. BIOS does not configure I/O systems to share PCI interrupts when APIC is activated

This applies to boot devices configured by the BIOS. The operating system should configure all other devices. For systems that will run the Windows family of operating systems and where the platform hardware can be configured to avoid sharing, OEMs must design the BIOS so that it does not configure the I/O systems in the PC to share PCI interrupts for boot devices.

Mobile PC Note

In mobile systems, the BIOS can configure the I/O system to share PCI interrupts.

BIOS–0017. BIOS configures boot device IRQ and writes to the interrupt line register

This requirement applies to boot devices configured by the BIOS. Windows must configure all other devices because, after an interrupt request (IRQ) is assigned by the system BIOS, Windows cannot change the IRQ. If the BIOS assigns the IRQ and Windows needs it for another device, a sharing problem occurs.

The BIOS must configure the boot device IRQ to a PCI-based IRQ and must write the IRQ into the interrupt line register 3Ch, even if the BIOS does not enable the device. This way, the operating system can still enable the device with the known IRQ at configuration time, if possible.

BIOS–0018. System BIOS supports ATA

ATA BIOS or option ROM must provide boot support for the primary ATA Packet Interface (ATAPI) bootable floppy disk drive in compliance with ATAPI Removable Media Device BIOS Specification, Version 1.0. Complying with this specification provides Int 13h and Int 40h support for bootable floppy drives as the primary or secondary floppy disk device.

The system BIOS must configure the drive and host controller so they are optimized for ATA operation. The programmed I/O mode must continue to work. The ATA/ATAPI device driver must also support restoration of these settings using the ACPI control methods _GTM, _STM, and _GTF when the ATA controller is power managed across a suspend and resume cycle.

BIOS–0019. BIOS enumeration of all ATAPI devices complies with ATA/ATAPI-5

The AT Attachment with Packet Interface – 5 (ATA/ATAPI-5) standard defines the enumeration process for all ATAPI devices.


PC 2001 Physical Design Requirements

This section summarizes physical design requirements for PC 2001 systems. These requirements are in addition to those related to the OnNow and Instantly Available PC initiatives for power-state indicators and easily accessible power switches.

For requirements related to audible noise, see SYS–0003, "Hardware design supports OnNow and Instantly Available PC initiatives," and its supporting requirements.

SYS–0020. System and component design practices follow accessibility requirements

At a minimum, the OEM must do the following:

  • Make sure that the keyboard and other input devices work correctly with the Microsoft Accessibility features in Windows. For example, StickyKeys must work with all keys in any keyboard design.
  • Make all modifier keys, such as the Ctrl and Shift keys, capable of being read and operated by software. This requirement includes the F1–F12 function keys and OEM-specific keys, such as Internet or Help keys. This capability allows users to access these keys and the functions that rely on them through operating system features, such as StickyKeys and SerialKeys, and through third-party software, such as voice recognition.


PC 2001 System Expansion Bus Requirements

This section provides requirements for all expansion buses included on PC 2001 systems.

SYS–0021. PC 2001 system includes USB with two user-accessible USB ports, minimum

System includes two user-accessible USB ports in addition to any used by the keyboard and pointing devices. USB must meet the requirements defined in Chapter 6, "Buses and Interfaces."

Mobile PC Note

For requirements to any implementation of USB on mobile PCs, see Chapter 5, "Mobile."

SYS–0022. If IEEE 1394 is implemented, all components meet PC 2001 requirements

If implemented, IEEE 1394 must meet the requirements defined in Chapter 6, "Buses and Interfaces" Notably, at least two externally accessible IEEE 1394 sockets are required when external access is provided. Internal-only IEEE 1394 implementations are also allowed.

Mobile PC Note

If implemented externally, mobile PCs require at least one externally accessible IEEE 1394 socket.

SYS–0023. System buses meet PC 2001 requirements

System buses must meet the requirements in Chapter 6, "Buses and Interfaces." This includes SCSI, ATA/ATAPI, and PCI, if implemented.

SYS–0024. If CardBus is implemented, all components meet PC 2001 requirements

If CardBus is implemented in a system, it must meet the requirements defined in PC Card and CardBus Guidelines, Version 1.1 .

CardBus cards must comply with Section 3 "PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges," in Volume 11 of the PC Card Standard, Release 7.

If wake-from-D3cold is implemented in a platform, the following are required:

  • Associated CardBus controller must support power management event (PME# assertion) from D3cold.
  • Associated socket must supply sufficient Vaux power to support the card in its D3cold state.


PC 2001 General Device Requirements

This section contains requirements that apply for every device, whether 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.

SYS–0025. Each device, device driver, and installation of either device or driver, meet PC 2001 requirements

Each device must comply with all requirements defined in this guide for the related device class, whether the device is provided in the PC system as an expansion card or as an external device.

In addition to the device requirements in this section, see also the specific requirements for each device class in this guide.

  • SYS–0025.1. Driver installation does not interfere with other devices. The installation and loading of a driver must not reduce or eliminate functionality of other devices installed on the system.
  • SYS–0025.2. Devices with WDM support in Windows include WDM-based drivers. Devices with WDM support in Windows include WDM-based drivers. If WDM support is provided in the operating system for a device type, the driver supplied by the manufacturer must be a WDM minidriver. This requirement applies whether the system is designed for use with Windows Me or Windows 2000.
  • SYS–0025.3. Driver supports Plug and Play and power management IRPs. Every driver (or minidriver) must support Plug and Play and power management I/O request packets (IRPs). This requirement applies whether the system is designed for use with Windows Me or Windows 2000.

For virtual device drivers (VxD) for Windows Me, the following requirements apply:

  • Every VxD must support Plug and Play and power management messages.
  • The driver must provide power management support as required by any related device class power management reference specification.

For information about Plug and Play support under Windows 2000, see the Windows 2000 DDK.

  • SYS–0025.4. All configuration settings are stored in the registry. The driver must not use INI files for configuration settings.

The driver must also include correct provider, version, and copyright entries. This information is displayed in Device Manager in Windows.

  • SYS–0025.5. All INF and other file information is correct. The correct minidriver, VxDs, or any other manufacturer-supplied files specified in the device’s information file (INF) must be installed in the correct location.

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.

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 upon with Microsoft.

For information about creating correct INF files under Windows 2000, see "Creating Windows 2000 INF Files" in the Windows 2000 DDK.

  • SYS–0025.6. Installation uses methods defined in the DDK. Driver installation and removal must use Windows-based methods, as defined in the Windows 98 DDK and Windows 2000 DDK.

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 its own remove utility. For information, see the driver installation information in the \SRC\General directory in the Windows 2000 DDK; see also "Windows 95 Class Installers and Network Driver Installers" in the Windows 95 DDK.

Also, any software components and registry entries installed during driver installation must be removed when the driver is removed.

SYS–0026. Each bus and device meets Plug and Play specifications

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

Any legacy components remaining in a legacy-reduced system must meet the requirements defined in Legacy Plug and Play Guidelines, which contains all the requirements for legacy Plug and Play as published in PC 99 System Design Guide.

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

  • PCI Local Bus Specification, Revision 2.2.
  • Plug and Play External COM Device Specification, Version 1.0.
  • Plug and Play ISA Specification, Version 1.0a and Clarifications to Plug and Play ISA Specification, Version 1.0a.
  • Plug and Play Parallel Port Device Specification, Version 1.0b.
  • Universal Serial Bus Specification, Revision 1.1.

Plug and Play specifications for IEEE 1394 are defined in this guide. For information, see "Plug and Play for IEEE 1394" in Chapter 6, "Buses and Interfaces."

SYS–0027. Unique Plug and Play device ID provided for each system device and add-on device

Each device connected to an expansion bus must be able to supply its own unique ID. The following are the specific requirements for Plug and Play device IDs:

  • Each separate function or device on the system board must be separately enumerated; therefore, each must provide a device ID in the manner required in the current Plug and Play specification for the bus it uses.
  • If a device on an expansion card is enumerated, it must have a unique ID and its own resources according to the current device ID requirements for the bus to which the card is connected.

In addition, for systems designed for use with Windows 2000, if an OEM uses a proprietary mechanism to assign asset or serial numbers to hardware, this information must be available to the operating system using Windows hardware instrumentation technology, as defined in the Windows Hardware Instrumentation Implementation Guidelines, Version 1.0 (WHIIG).

Legacy devices attached to the ISA bus on the system board are not required to have unique Plug and Play IDs—for example, serial ports, parallel ports, or PS/2 compatible port devices. For information, see Legacy Plug and Play Guidelines .

SYS–0029. Minimal user interaction needed to install and configure devices

After physically installing the device, the user need not perform any action other than inserting the disks that contain drivers and other files. The user should only be required to restart the system for devices that do not support hot plugging.

The following requirements must be met.

  • SYS–0029.1. The device is immediately functional without restarting the system. It is acceptable to require rebooting for the primary graphics adapter and the primary hard disk controller. ATA drives need not implement Cable Select (CS) settings. In all cases, however, changing configuration settings must not require the end user to make jumper changes.
  • SYS–0029.2. Software settings 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 the Device Manager in Windows, so that the user does not need to open the PC case to change the configuration. Dual in-line package (DIP) switches on boot devices are allowed for an initial power-on default state or for non-Plug and Play system compatibility, but such settings must be capable of being overridden by software configuration after power on occurs under Plug and Play operating systems.

Note: This requirement does not apply for jumper settings used by the OEM to set CPU speed, select a keyboard, or make other basic system-related settings in the factory. This requirement applies only for settings that the end user must make to configure the hardware.

  • SYS–0029.3. Dynamic disable capabilities are supported for all devices. All devices must be capable of being automatically disabled by the system. Also, disabling the device must result in the freeing of all its resources for use by other devices.

The following devices are exempt from this requirement: all legacy devices using the I/O range under 100h, 8042 keyboard controller, legacy FDC, HDC, video graphics array (VGA) memory and I/O addresses, and any BIOS memory ranges required for legacy boot support.

SYS–0030. Hot-plugging capabilities for buses and devices meet PC 2001 requirements

To provide reliable support for hot-plugging capabilities, the following requirements must be met.

  • SYS–0030.1. USB, IEEE 1394, and PC Card devices and buses support hot-plugging. USB, IEEE 1394, and PC Card specifications all support hot-plugging. A device designed to use any of these connections must support being added or removed while the system is fully powered on.
  • SYS–0030.2. System supports hot-plugging for any PCI devices that use ACPI-based methods. Hot-plugging is not required for PCI devices. Windows Me and Windows 2000 support dynamic enumeration, installation, and removal of PCI devices only if there is a supported hardware insert/remove notification mechanism. An example of an appropriate notification mechanism such as a bus standard is that provided by CardBus bus controllers. Other implementations, such as those for docking stations and hot-plugging of PCI devices, must comply with the hardware insert/remove notification mechanism as defined in Section 5.6.3 of the ACPI 1.0b specification. It should be noted that systems implementing hot-pluggable PCI capabilities compliant with the PCI Hot-Plug Specification, Revision 1.0, must still provide the hardware insert/remove notification mechanism as defined in Section 5.6.3 of ACPI 1.0b.

More information about Windows 2000 and PCI Hot-Plug can be found on the Web page listed in "PC System References."

  • SYS–0030.3. All removable media support media status notification. For details and for design requirements, see Chapter 12, "Storage."
  • SYS–0030.4. If implemented, system supports smart card specifications. If smart card is implemented, system must support ISO/IEC specifications. See SMRT–0153, "Smart card reader complies with ISO/IEC 7816," in Chapter 7.

For implementation details and additional design requirements, see "Supporting Removable Devices under Windows," the section about hot-plugging, listed in "PC System References."

SYS–0031. If implemented, Device Bay components comply with Device Bay 1.0

If implemented in a PC 2001 system, Device Bay capabilities must meet the following requirements:

  • The system includes a Device Bay Controller (DBC) compliant with Device Bay Specification, Version 1.0 or later. If the DBC is implemented as a USB device, it must be compliant with Universal Serial Bus Device Class Definition for Device Bay Controllers, Version 1.0.
  • The system includes one USB port and one IEEE 1394 port for each Device Bay-capable bay in the system.

Any Device Bay peripheral that is provided with a PC 2001 system must meet the following requirements:

  • Device complies with Device Bay Specification, Version 1.0.
  • Device uses either the USB bus, the IEEE 1394 bus, or both.
  • If the device uses the USB bus, it must also comply with the relevant USB device class specifications.
SYS–0032. Multifunction device meets PC 2001 device requirements for each device

Multifunction devices can contain more than one device. They must comply with requirement SYS–0025, "Each device, device driver, and installation of either device or driver, meet PC 2001 requirements," including the requirements for automated software-only settings for device configuration, device drivers, and Windows-based installation. In addition, multifunction devices must meet the following requirements.

  • SYS–0032.1. Each enumerated device has a unique device ID. Each function or device on the multifunction add-on device that is individually enumerated must provide a device ID for the bus it uses.
  • SYS–0032.2. Windows can separately access and configure each logical device. Windows must be able to separately access each logical device that is individually enumerated, configure the device resources independently, and disable individual devices in the event of a conflict.
  • SYS–0032.3. Each enumerated device meets its own resource requirements. 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 among individually enumerated devices on a multifunction add-on device, but it does not supersede device requirements among different bus classes.
  • SYS–0032.4. For PC 2001, separate drivers are required for separate functions. Note that a supervisory driver that loads different drivers for the individual functions does not work well with Windows. In particular, driver support is likely to be lost in cases of operating system re-installation or upgrade, or with distribution of new drivers via Windows Update. Therefore, these supervisory drivers must be avoided.
  • SYS–0032.5. There are no start order dependencies between drivers for separate functions. The operating system must be able to configure and manage functions and devices in any order, so drivers for a multifunction device may not depend on another driver to be started before the function or device can be used.
  • SYS–0032.6. Independent functions and devices can be used concurrently, with no hidden dependencies. Separate functional units in a multifunction device must be able to operate concurrently, without interfering with each other or with other devices in the system.
  • SYS–0032.7. Each function and device can be power managed independently. Each function and device in a multifunction device must separately meet the power management device class specifications for its device class and be independently power managed. Each function and device must be able to successfully complete a system sleep/wake transition (where the unit transitions from D0 to D3 with power removed to D0) without losing functionality and without requiring user intervention to restore functionality. All functions and devices that support wakeup capabilities must correctly support wake from D3 with power removed.
SYS–0033. Each bus meets written specifications and PC 2001 requirements

Each bus and connector used in the system must meet all the requirements for that bus as defined in Chapter 6, "Buses and Interfaces." For CardBus, see PC Card and CardBus Guidelines, Version 1.1 . See also SYS–0026, "Each bus and device meets Plug and Play specifications."

SYS–0034. If implemented as an industry-standard riser card, the riser device subsystem complies with applicable standard Plug and Play requirements

All industry standard riser cards must provide means for the device to uniquely identify each function, so that the system (including the BIOS) can generate unique PCI Subsystem Vendor ID (SVID) and Subsystem Device IDs (SDIDs) as required in SYS–0027, "Unique Plug and Play device ID provided for each system device and add-on device."

Riser devices, including audio, modems, and network adapters, must supply a unique device ID for each version of the riser that needs a different driver. The device must also expose a different set of Plug and Play device IDs for each function as required in SYS–0032, "Multifunction device meets PC 2001 device requirements for each device."

Examples of these risers include:

  • An audio modem riser (AMR) card that complies with the Audio/Modem Riser Card Specification, listed in "PC System References."
  • Communications and networking riser. For more information, see the Communications and Networking Riser Web site, listed in "PC System References."
  • Advanced communications riser.


PC 2001 Graphics and Video Requirements

The following requirements describe video requirements in a PC 2001 system.

SYS–0035. If DVD-Video playback is implemented, PC 2001 system provides video playback capabilities

Video playback capability is required in PC 2001 systems. PCs must be capable of decoding MPEG streams, however this is not a requirement to ship an MPEG decoder with the system. Systems must meet the requirements under "MPEG-2 Video Playback Requirements" and "DVD-Video Playback Requirements" in Chapter 9.

Mobile PC Note

Mobile PC 2001 systems require support of 640 × 480, 16 bpp mode only.

SYS–0036. If video capture is implemented, analog video input and capture capabilities comply with PC 2001 requirements

If video-capture capability is implemented in a PC 2001 system, it must meet the requirements VID–0210, "Video input, capture, and broadcast device support is based on DirectX foundation class and WDM Stream class or AV Stream class"; VID–0224, "If implemented, video input or capture device provides raw sampled VBI data to the host"; and VID–0225, "If implemented, VBI capture oversamples VBI data exactly 4.7 or 5 times," in Chapter 9.

SYS–0037. If Digital Video Interface is implemented, components comply with PC 2001 requirements

Digital interfaces for monitors comply with Digital Visual Interface (DVI), Revision 1.0. See MON–0241, "Digital display interface is DVI compliant," in Chapter 10.


PC 2001 Storage Requirements

The following storage requirements apply to all PC 2001 systems.

SYS–0038. PC 2001 system includes hard disk and controller

The host controller for hard disk devices must support bus mastering. Bus master capabilities must meet the related specification for the particular controller.

Storage bus devices must not use the ISA bus.

Hard disk and optical devices must meet the requirements defined in Chapter 12, "Storage."

Note: This requirement does not apply for closed-case platforms that do not include an HDD and are designed to boot from the network.

SYS–0039. PC 2001 system includes either CD or DVD drive and controller

The CD or DVD drive and controller must meet the requirements defined in Chapter 12, "Storage."

Note: This requirement does not apply for closed-case platforms that do not include an HDD and are designed to boot from the network.

Mobile PC Note

For requirements for mobile PC systems, see MOBL–0072, "If implemented, CD or DVD drive meets PC 2001 requirements," in Chapter 5.


Legacy Removal Requirements

This section defines the hardware and BIOS requirements for legacy-reduced and legacy-free systems. For background information about the goals of legacy removal for PC 2001, see "Legacy Removal and Easy PC Goals" in Chapter 2, "Easy PC Initiative."

All PC 2001 computers accomplish some level of legacy removal, as indicated in the following subsection, "PC 2001 Legacy Reduction Requirements." For system designers who want the operating system to identify the computer as a legacy-free system, the "PC 2001 Legacy Free Requirements" section that appears later in this chapter contains additional requirements.


PC 2001 Legacy-Reduced System Requirements

This section defines requirements for migration away from legacy architectures for all PC 2001 systems.

SYS–0041. System does not include ISA expansion devices or slots

PC 2001 systems do not include any ISA expansion devices or user-accessible ISA slots.

Systems that are not designed to meet PC 2001 legacy-free requirements can use ISA or ISA-like protocols and signaling for implementations of legacy devices such as the controllers for serial, parallel, 8042, floppy disk drive, and so on. For information, see Legacy Plug and Play Guidelines

SYS–0042. Preinstalled components and upgrades do not require MS-DOS or legacy interfaces

Peripherals included with the system must offer a non-legacy interface such as PCI, USB, USB 2.0, SCSI, IEEE 1394, or CardBus. Peripherals can include both a legacy interface and a non-legacy interface. Proprietary interfaces are not acceptable.

The keyboard and pointing devices can use a PS/2 compatible interface.

SYS–0067. Secondary boot and upgrade capability is independent of FDC-based floppy disk drive

The system must be capable of recovery and upgrade of the hard drive image and BIOS independent of an FDC-based floppy disk drive. Options include a CD or DVD drive attached to USB, ATA, IEEE 1394, or SCSI.

Note: This requirement does not apply to Windows NT 4.0 recovery media that ships or is offered with the system.

Recovery storage devices do not have to be CD- or DVD-based, but must include recovery media from the OEM that does not limit upgrades from production optical media.


PC 2001 Legacy-Free System Requirements

This section defines the hardware requirements for legacy-free systems that will be implemented under PC 2001 requirements.

The basic goal for the legacy-free system requirements is that the operating system and devices do not use any of the following:

  • ISA slots or devices
  • Legacy FDC
  • PS/2, serial, parallel, and game ports

Revisions to the ACPI specification provide a mechanism that allows the BIOS to report whether a system provides the services of these components and interfaces. If the BIOS reports that the system is legacy free, the system must meet the requirements provided in this section.

Note: The requirements for legacy-free systems are additional to those defined in "PC 2001 Legacy Reduction Requirements."

BIOS–0043. BIOS supports required interrupts

The list in Appendix A, "Resource Mapping," shows the known BIOS dependencies for which support is required. All subfunctions must be present on a legacy-free PC 2001 system as described in Appendix A.

BIOS–0013. BIOS supports legacy removal

The BIOS does not include boot dependencies on ISA, and no ISA-related components appear on BIOS setup screen.

BIOS–0045. No legacy ports detected

The following ports are considered legacy ports and must be replaced by USB or other non-legacy equivalents:

  • FDC
  • Serial
  • Parallel
  • PS/2-compatible ports
  • ISA-based game ports and MPU 401 (Musical Instrument Digital Interface [MIDI]) ports

These ports must not be available for external connection and must not be detected by the operating system as enabled.

In addition, the 8042 controller can be present and reported through ACPI, although PS/2-compatible ports cannot be provided for connecting external devices.

Systems can provide Super I/O-based IrDA support.

Mobile PC Note

New docking stations designed specifically for legacy-free mobile PCs must follow these requirements. This does not preclude existing docked mobile PC designs from being used with legacy-free mobile PCs.

The following table shows the I/O addresses and interrupts related to the restricted legacy devices. Do not use these resources except as noted in the table. If hardware is present and disabled, ACPI declaration must claim the resources so they cannot be freed.

Restricted Port Addresses

Device | I/O Address | Interrupts
COM 1 | 2E8–2EF 2F8–2FF2 3E8–3EF 3F8–3FF | IRQ32, IRQ4
LPT | 278–27A 378–37A 3BC–3BE | IRQ 7
Joystick/game port | 0200–020F |
Sound Blaster | 0220–022F |
MPU-401 (MIDI) | 0330–0331 |
FDC | 3F0–3F7 | IRQ 6

1 An internal COM port header can be used as a debug port solution if the COM port is not exposed to the end user. In this case, the COM port must not use the I/O addresses listed in this table; the relocated COM I/O address must be reported in the ACPI Debug Port table.

2 An IrDA controller is permitted to use these resources.

SYS–0040. If implemented, floppy disk capabilities do not use legacy FDC

To support migration away from legacy devices, floppy disk drives on PC 2001 systems must be based on a solution other than an FDC. Solutions include: ATAPI floppy disk drive compliant with SFF-8070i, USB, IEEE 1394, PC Card, or SCSI-based floppy disk drives.

The device and its controller must meet the general requirements defined in Chapter 12, "Storage."

SYS–0047. A20M# is always de-asserted (pulled high) at the processor

If A20M# generation logic is still present in the system, this logic must be terminated such that software writes to I/O port 92, bit 1, do not result in A20M# being asserted to the processor.

SYS–0046. System supports legacy-free debug capabilities
  • Legacy-free systems must implement a debug solution that complies with the Debug Port Specification, listed in "PC System References."


Manageability Component Instrumentation Requirements

This section presents new requirements for PC 2001 systems related to the Wired for Management (WfM) initiative and the Zero Administration initiative for Windows. The WfM initiative seeks to raise the level of management capabilities for mobile, desktop, and workstation platforms. The Zero Administration initiative seeks to provide a controlled, highly manageable enterprise.

The baseline for these requirements is Windows Hardware Instrumentation Implementation Guidelines, Version 1.0, which also defines the Windows-specific requirements of the Wired for Management Baseline Specification, Version 2.0, for hardware instrumentation.

Collectively, the items in this section represent the Manageability Baseline requirements for Windows 2000.

SYS–0048. System supports WHIIG

The related requirement is defined in Windows Hardware Instrumentation Implementation Guidelines, Version 1.0.

Mobile PC Note

Support for WHIIG, WMI, and enabling a management information service provider is required for mobile systems targeted for use with Windows 2000.

SYS–0049. Expansion devices on desktop systems can be remotely managed

Devices provided as expansion devices must be capable of being remotely managed so that control and Total Cost of Ownership (TCO) policies can be realized. For example, for any implementation of a floppy disk drive on a Windows 2000 system, the drive must be capable of being remotely disabled as a boot selection and provisions must be made for locking.

Certain devices are not required to be capable of being remotely disabled, including the primary HDD, the network adapter, and any standard devices that use legacy connections, such as a keyboard or pointing device that uses a PS/2-compatible connection. However, it must be possible that permissions, policies, or other methods can be used to remotely manage capabilities such as hard disk access or to control end-user ability to change the MAC address or configuration settings for the network adapter.

See also requirement BIOS–0014, "BIOS supports remote boot."


PC System References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Advanced Configuration and Power Interface Specification, Revision 1.0b

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

AT Attachment with Packet Interface – 5 (ATA/ATAPI-5)

ftp://fission.dt.wdc.com/pub/standards/x3t13/project/d1321r3.pdf

ATAPI Removal Rewriteable Media Devices (INF-8070i)

ftp://fission.dt.wdc.com/pub/standards/SFF/specs/INF-8070.pdf

ATAPI Removable Media Device BIOS Specification, Version 1.0

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

BIOS Boot Specification, Version 1.01

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

Boot Integrity Services Application Programming Interface, Version 1.0

http://developer.intel.com/ial/wfm/wfmspecs.htm

Common Application Environment (CAE) Specification

http://www.opengroup.org/onlinepubs/9629399/toc.htm

Communications and Networking Riser Web site

http://developer.intel.com/technology/cnr/

Debug Port Specification

http://www.microsoft.com/hwdev/NewPC/debugspec.htm

Default Device Class Power Management Reference Specification, Version 1.0, and other device class power management specifications

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

Device Bay Specification, Version 1.0

http://www.device-bay.org

Digital Visual Interface (DVI), Revision 1.0

http://www.ddwg.org

"El Torito"—Bootable CD-ROM Format Specification, Version 1.0

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

Hot-Plug PCI and Windows 2000 Web page

http://www.microsoft.com/hwdev/pci/hotplugpci.htm

Instantly Available PC System Power Delivery Requirements and Recommendations

http://developer.intel.com/design/power/supply98.htm

Instantly Available Power Managed Desktop PC Design Guide

http://developer.intel.com/technology/iapc/tech.htm

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/LegacyPnP/

OnNow and Power Management Web page

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

PC Card and CardBus Guidelines, Version 1.1

http://www.pcdesguide.org/documents/pccard.htm

PC Card Standard, Release 7

http://www.pcmcia.org/bookstore.htm

PCI Hot-Plug Specification, Revision 1.0

http://pcisig.com/tech/index.html

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/developers/specification/

Plug and Play External COM Device Specification, Version 1.0
Plug and Play ISA Specification, Version 1.0a and Clarifications to the Plug and Play ISA Specification, Version 1.0a
Plug and Play Parallel Port Device Specification, Version 1.0b

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

Preboot Execution Environment (PXE) Specification, Version 2.1

http://developer.intel.com/ial/wfm/wfmspecs.htm

"Scan Codes for Keyboard Power Switches"

http://www.microsoft.com/hwdev/desinit/scancode.htm

"Supporting Removable Devices under Windows"

http://www.microsoft.com/hwdev/busbios/rem_devs.htm

System Management BIOS Reference Specification, Version 2.3

ftp://download.intel.com/ial/wfm/smbios.pdf
http://www.phoenix.com/techs/specs.html

Universal Serial Bus Device Class Definition for Device Bay Controllers, Version 1.0
And other USB device class specifications

http://www.usb.org/developers/devclass_docs.html

Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1

http://www.usb.org/developers/data/devclass/hid1_1.pdf

Universal Serial Bus Specification, Revision 1.1

http://www.usb.org/developers/docs.html

Windows 95 DDK, Windows 98 DDK, and Windows 2000 DDK

http://www.microsoft.com/ddk/

"Creating Windows 2000 INF Files"

http://www.microsoft.com/hwdev/NTDRIVERS/w2inf.htm

Windows Hardware Instrumentation Implementation Guidelines, Version 1.0
White papers and guidelines for WMI

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

Wired for Management Baseline, Version 2.0

http://developer.intel.com/ial/wfm/


Checklist for PC System

SYS–0001. System performance meets PC 2001 minimum requirements

SYS–0002. System design meets ACPI 1.0b specification and PC 2001 requirements

SYS–0003. Hardware design supports OnNow and Instantly Available PC initiatives

BIOS–0004. BIOS meets PC 2001 requirements for OnNow/Instantly Available PC support

BIOS–0005. BIOS includes local boot support

BIOS–0006. BIOS supports SMBIOS 2.3

BIOS–0007. BIOS and CMOS properly accommodate all dates

BIOS–0008. BIOS supports security

BIOS–0009. BIOS supports BIOS updates and revisions

BIOS–0010. System BIOS supports debug port

BIOS–0011. System BIOS and option ROMs support Int 13h Extensions

BIOS–0012. ROM BIOS interrupt handlers preserve values in all registers

BIOS–0014. BIOS supports remote boot

BIOS–0015. BIOS supports ACPI legacy-free reporting mechanism

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

BIOS–0017. BIOS configures boot device IRQ and writes to the interrupt line register

BIOS–0018. System BIOS supports ATA

BIOS–0019. BIOS enumeration of all ATAPI devices complies with ATA/ATAPI-5

SYS–0020. System and component design practices follow accessibility requirements

SYS–0021. PC 2001 system includes USB with two user-accessible USB ports, minimum

SYS–0022. If IEEE 1394 is implemented, all components meet PC 2001 requirements

SYS–0023. System buses meet PC 2001 requirements

SYS–0024. If CardBus is implemented, all components meet PC 2001 requirements

SYS–0025. Each device, device driver, and installation of either device or driver, meet PC 2001 requirements

SYS–0026. Each bus and device meets Plug and Play specifications

SYS–0027. Unique Plug and Play device ID provided for each system device and add-on device

SYS–0029. Minimal user interaction needed to install and configure devices

SYS–0030. Hot-plugging capabilities for buses and devices meet PC 2001 requirements

SYS–0031. If implemented, Device Bay components comply with Device Bay 1.0

SYS–0032. Multifunction device meets PC 2001 device requirements for each device

SYS–0033. Each bus meets written specifications and PC 2001 requirements

SYS–0034. If implemented as an industry-standard riser card, the riser device subsystem complies with applicable standard Plug and Play requirements

SYS–0035. If DVD-Video playback is implemented, PC 2001 system provides video playback capabilities

SYS–0036. If video capture is implemented, analog video input and capture capabilities comply with PC 2001 requirements

SYS–0037. If Digital Video Interface is implemented, components comply with PC 2001 requirements

SYS–0038. PC 2001 system includes hard disk and controller

SYS–0039. PC 2001 system includes either CD or DVD drive and controller

SYS–0041. System does not include ISA expansion devices or slots

SYS–0042. Preinstalled components and upgrades do not require MS-DOS or legacy interfaces

SYS–0067. Secondary boot and upgrade capability is independent of FDC-based floppy disk drive

BIOS–0043. BIOS supports required interrupts

BIOS–0013. BIOS supports legacy removal

BIOS–0045. No legacy ports detected

SYS–0040. If implemented, floppy disk capabilities do not use legacy FDC

SYS–0047. A20M# is always de-asserted (pulled high) at the processor

SYS–0046. System supports legacy-free debug capabilities

SYS–0048. System supports WHIIG

SYS–0049. Expansion devices on desktop systems can be remotely managed


Chapter 4 Workstation

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

Workstation PC is a platform for users whose principal computing tasks involve running mission-critical networked applications, engineering or scientific applications, media authoring tools, or software development tools. While there is not a set of differentiating characteristics that define a workstation PC, this chapter provides the relevant requirements for workstations designed as PC 2001 systems. As defined herein, a workstation is optimized to run Windows 2000 and future versions of the Windows 2000 client operating system. The defined platform also supports Win32-based and Win64TM-based applications.

All PC 2001 system and component requirements also apply to workstations unless this chapter provides redefinition or extension of a specific requirement if implemented in workstations.


Workstation System Design Requirements

This section summarizes the additional design requirements and exceptions for workstation PC 2001 systems.

WORK–0051. Workstation system components meet minimum performance requirements

Minimum Workstation PC 2001 system component requirements include the following.

  • WORK–0051.1. System CPU speed is 700 MHz, minimum.
  • WORK–0051.2. System has 256 KB of cache per processor, minimum, present and enabled.
  • WORK–0051.3. System memory is 128 MB RAM, minimum.
  • WORK–0051.4. RAM must be capable of expansion to 2 GB, minimum.
WORK–0052. If implemented as a multiple processor system, the system must meet PC 2001 requirements

Workstations implementing multiple processors must meet the following requirements.

  • WORK–0052.1. The system must employ those processors symmetrically.
  • WORK–0052.2. Each processor must have a separate cache.
  • WORK–0052.3. The system memory and external processor cache are protected with ECC memory protection. See SYS–0054, "If implemented, system memory includes ECC memory protection" in Chapter 3.
  • WORK–0052.4. The system must comply with the ACPI 1.0b specification. Windows NT 4.0 was the last Windows operating system to use the MultiProcessor Specification, Version 1.4 (MPS 1.4). MPS 1.4 is a requirement for multiprocessor platforms running Windows NT 4.0.
WORK–0055. If implemented as a 64-bit system, PCI bus, bridges, and adapters support DAC command

On 64-bit workstation platforms that provide support for more than 4 GB of system memory, all PCI adapters, including 32-bit PCI adapters, must function properly in the system. In addition, certain classes of adapters, such as those on the primary data path where the majority of network and storage I/O occurs, must also address the full physical address space of the platform. For 32-bit PCI adapters on the primary data path, this means that the adapter must be able to support the PCI Dual Address Cycle (DAC) command. Note that 10/100 Ethernet adapters and embedded devices do not need to support DAC; however, 10/100 Ethernet adapters and embedded devices must still function properly in those systems even if they do not implement DAC support.

Additionally, all 32-bit PCI buses, host bridges, and PCI-to-PCI bridges must also support DAC.

On 64-bit platforms, all PCI bridges on the system board must support DAC for inbound access, and DAC-capable devices must not be connected below non-DAC capable bridges, on adapter cards, for example. New 64-bit adapters should be DAC capable. This DAC requirement does not apply to outbound accesses to PCI devices; however, for systems where DAC is not supported on outbound accesses to PCI devices, the system BIOS must not claim that the bus aperture can be placed above the 4 GB boundary.

System designers must address special considerations when using legacy devices, adapters, and bridges in systems that provide support for more than 4 GB of memory. For information on Windows 2000 behavior when a non-DAC capable bus is detected on a system that supports more than 4 GB of memory, see the PAE Server Design Web page, listed in "Workstation References."

WORK–0056. Workstation supports 64-bit I/O bus architecture if system includes 64-bit processors

A 64-bit PCI adapter must address any location in the address space supported by the platform.

The workstation must support a 64-bit PCI bus if the workstation has 64-bit processors or has the capability to support greater than 4 GB of physical memory.

SYS–0058. For 64-bit platforms, each device and driver meets PC 2001 device requirements

For workstations implementing a 64-bit platform, each device included within the workstation must have 64-bit Windows 2000 compatible drivers.

WORK–0059. Graphics subsystem supports workstation performance demands

The graphics-intensive application requirements for hardware often exceed the hardware capabilities of the graphics subsystem.

  • WORK–0059.1. Workstation screen resolution meets minimum requirements. For workstations, minimum graphics resolution is 1280 × 1024 × 32 bpp, double buffered in 2-D mode with a 32-bit Z-buffer (defined as 24-bit Z with 8-bit stencil) in 3-D mode.
  • WORK–0059.4. If implemented, an AGP Pro Bus follows the AGP Pro 1.1 Specification, Revision 1.1a.
WORK–0060. If implemented, multiple hard-drive system meets workstation PC 2001 performance requirements

When implementing a workstation storage subsystem capable of supporting multiple hard drives, the hard drives must either be allocated independent ATA Ultra/66 I/O channels (one channel per physical storage device) or may be grouped and interconnected using SCSI interfaces. This requirement ensures workstation data throughput while allowing less costly ATA interfaces on systems that require only a few drives.

If implementing a RAID drive storage subsystem, these arrays can be configured as:

  • RAID 0: Improve performance (multiple spindle access and striping).
  • RAID 1: Data mirroring on parallel drives.
  • RAID 5: For data integrity using distributed data and cyclic redundancy checks (CRCs).

For all related requirements for storage, see Chapter 12, "Storage."

PCIX–0129. If the workstation implements PCI-X, system and components comply with PCI-X 1.0

All cards, bridges, and devices that use PCI-X (a proposed extension to PCI) must meet the requirements defined in PCI-X Specification, Revision 1.0, listed in "Workstation References."


Workstation References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Advanced Configuration and Power Interface Specification, Revision 1.0b

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

AGP Pro Specification, Revision 1.1a

http://www.agpforum.org/downloads/apro_r10.pdf

PAE Server Design

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

PCI-X Specification, Revision 1.0

http://www.pcisig.com/


Checklist for Workstation

WORK–0051. Workstation system components meet minimum performance requirements

WORK–0052. If implemented as a multiple processor system, the system must meet PC 2001 requirements

WORK–0055. If implemented as a 64-bit system, PCI bus, bridges, and adapters support DAC command

WORK–0056. Workstation supports 64-bit I/O bus architecture if system includes 64-bit processors

SYS–0058. For 64-bit platforms, each device and driver meets PC 2001 device requirements

WORK–0059. Graphics subsystem supports workstation performance demands

WORK–0060. If implemented, multiple hard-drive system meets workstation PC 2001 performance requirements

PCIX–0129. If the workstation implements PCI-X, system and components comply with PCI-X 1.0


Chapter 5 Mobile

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter provides a summary of the PC 2001 requirements for mobile PCs, docking stations, and mini-docks. Mobile PC systems have trade-offs in thermal design, portability, battery run-time and battery life, size, weight, and connectivity that differ from the trade-offs made for desktop or workstation systems.

Unless a specific requirement or exception is defined in this chapter, all requirements apply for mobile PCs as defined elsewhere in this guide. If there is a conflict with requirements made elsewhere in this guide, the items in this chapter have precedence for mobile PCs.

Information on PC Card and CardBus requirements is listed in "Mobile References."


Mobile PC System Design Requirements

This section summarizes the additional design requirements and exceptions for mobile PCs.

MOBL–0061. Mobile PC performance meets Mobile PC 2001 minimum requirements

Minimum mobile PC 2001 performance requirements are:

  • MOBL–0061.1. Minimum 400 MHz processor
  • MOBL–0061.2. Minimum 128 KB of cache, present and enabled
  • MOBL–0061.3. 64 MB of RAM, minimum

Note: The processor requirement does not specify a particular processor form factor or package type.

MOBL–0062. Mobile PC supports Smart Battery or ACPI Control Method battery

A mobile PC must use a Smart Battery or an ACPI control method battery as follows.

  • MOBL–0062.1. If implemented, Smart Battery meets PC 2001 requirements. If Smart Battery is implemented, the following requirements apply:
  • An ACPI embedded controller-based (EC) System Management Bus (SMBus) interface is required, as described in Section 13 of ACPI 1.0b.
  • The Smart Battery must support the complete command set and meet the accuracy requirements defined in Smart Battery Data Specification, Revision 1.1.
  • A Smart Battery Charger, if used, must comply with the command requirements defined in Smart Battery Charger Specification, Revision 1.1.
  • Single battery system must comply with the intent of the Smart Battery System Manager Specification, Revision 1.0, and expose emulated Smart Battery System Manager registers to the operating system.
  • A multiple-battery system may use either a Smart Battery System Manager that complies with the Smart Battery System Manager Specification, Revision 1.0, or it may emulate the functionality of the Smart Battery System Manager. The battery selection or alternate control scheme must comply with the intent of the Smart Battery System Manager Specification. In either case, the multiple battery system must expose actual or emulated Smart Battery System Manager registers to the operating system.
  • Battery systems that support battery calibration must use the Smart Battery System Manager optional calibrate support bits in the BatterySystemStateCont register.

The intent is that battery systems returning Smart Battery system data by way of the EC SMBus interface as defined in the ACPI 1.0b specification do so in a manner consistent with the Smart Battery system specifications. They must return all battery data, the charger status, and all selector or system manager registers in a manner transparent to the operating system, allowing the standard Smart Battery system drivers provided with the operating system to work properly.

  • MOBL–0062.2. If implemented, ACPI Control Method Battery meets PC 2001 requirements. If an ACPI Control Method Battery is implemented, it must meet the requirements defined in Section 11 of ACPI 1.0b and never over-report its capacity.
MOBL–0063. Mobile PC includes at least one USB port

At least one USB port must be built into a mobile PC and not be provided solely by a docked mobile PC. Docked mobile PCs, however, provide extra USB connectors. This USB port can be either a high-power or low-power port, or it can be dynamically configurable at the discretion of the OEM, as provided for by Section 7 of the Universal Serial Bus Specification, Revision 1.1.

For additional information about USB ports and devices, see "USB" in Chapter 6.

MOBL–0064. If implemented, Mobile PC includes compliant IEEE 1394

The IEEE 1394 implementation must meet the IEEE 1394 device requirements found in Chapter 6, "Buses and Interfaces." If externally accessible sockets are provided, at least one IEEE 1394 supported socket must be provided.

MOBL–0065. Mobile PC includes CardBus

At least one 32-bit Type-2 CardBus slot (not 16-bit) is required. All CardBus implementations must comply with the requirements defined in Chapter 6, "Buses and Interfaces," including information about the default initialization of the CardBus controller under both Windows Me and Windows 2000 operating systems.

Information on PC Card and CardBus requirements is listed in "Mobile References."

MOBL–0066. Mobile PC keyboard and pointing device meet PC 2001 Mobile requirements

A mobile PC 2001 system must have an integrated pointing device and integrated input devices (keyboard or speech I/O).

The internal keyboard and any built-in pointing devices, such a mouse, stylus, pen, touch pad, touch screen, trackball, stick, and so on, required for a mobile PC must use standard system-board devices. The USB port can be used to support the requirement for external pointing device and keyboard connections.

For more information, see Chapter 7, "Input Devices," which also provides information about implementing the Windows and Application logo keys on mobile PCs.

MOBL–0069. Mobile PC meets PC 2001 Mobile graphics and video requirements

A mobile PC must meet the guidelines in Chapter 8, "Graphics Adapters," in addition to the guidelines listed below:

  • MOBL–0069.1. Mobile PC has integrated display.
  • MOBL–0069.2. Mobile PC provides PC 2001 Mobile graphics capabilities. Mobile PC meets all graphics requirements.
  • MOBL–0069.3. If implemented, external video connector meets mobile PC requirements. Mobile PCs are not required to include an external video connector. If an analog video connector is implemented, it can be either a VGA connector or DVI connector. If a digital monitor interface is implemented, a DVI connector is required.
  • MOBL–0069.4. If implemented, TV output meets mobile PC requirements. Mobile PCs are not required to include an external TV output.
MOBL–0070. Mobile PC includes PC 2001 hard disk as primary boot device

Mobile PC must include a PC 2001 hard disk as its primary boot device. The drive must meet the requirements in Chapter 12, "Storage."

MOBL–0071. Communications capabilities meet Mobile PC 2001 requirements

The presence of a CardBus slot on the mobile PC meets the PC 2001 requirement for providing access to the LAN and WAN, with the following exceptions:

  • If modem capabilities are integrated in the base platform, the requirements for modems must be met as defined in Chapter 13, "Modems."
  • For a network adapter, support is optional, rather than required, for remote new system setup capabilities. All other requirements for network communications must be met as defined in Chapter 14, "Network Communications."
  • Support for remote wakeup is not required to be built into mobile PCs.
MOBL–0072. If implemented, CD or DVD drive meets PC 2001 requirements

If a mobile PC includes a CD or DVD drive, it must meet the requirements in Chapter 12, "Storage." The mobile PC must also support booting from the drive, whether it is integrated into the platform, contained in a user exchangeable bay device, or attached to the system by a dongle or other cable.

A mobile PC system, as purchased, might not include all peripherals required for operating system installation. This basic PC 2001 requirement is met as long as it is possible for the user to obtain the required device support for operating system installation, even if it requires a separate purchase.


Port Replicator and Docking Station Requirements

Docking stations and port replicators are expansion devices that physically mate to the mobile PC and provide cable management. Docking stations include feature enhancements such as PCI slots, network adapters, PC Card slots, and storage devices.

Expansion devices that connect to the mobile PC by a cable and use buses such as serialized PCI, USB, IEEE 1394 or a wireless connection, must meet their respective industry standards and requirements as specified in the appropriate bus and device chapters in this guide.

The requirements in this section apply for mobile PC that supports a docking system or port replicator. A mobile PC is not required to have a docking system.

For all port replicator implementations, the appropriate requirements in the bus chapter apply unless specific exceptions or additional requirements are listed in this section.


Port Replicator Definition

For the purposes of these requirements, a port replicator is an acceptable method for adding the following functionality to a mobile PC.

  • Cable management by passing through the following connectors and buses. All the following pass-through connections must be compliant with their respective requirements, specifications, and standards:

Any bus used exclusively for manageability

Audio, including line-in, line-out, microphone, and headphone

Floppy drive

Game port

IEEE 1394 PHY (see note)

LAN

MIDI port

Modem

Parallel or LPT port

PS/2 port

Serial port

USB connector: pass-through connector is allowed to be low power

Video

Note: The IEEE 1394 socket available in the port replicator must meet the requirements for externally accessible IEEE 1394 sockets according to
1394–0093, "If the IEEE 1394 implementation provides external connectivity, system must use only sockets specified by IEEE 1394-1995 and its amendments" in Chapter 6.

  • USB hub

USB hub is compliant with requirements listed in Chapter 6, "Buses and Interfaces."

  • Power supply (if needed)


Docking Station Requirements

This section describes the requirements for docking stations or docked mobile PCs.

For the purposes of these requirements, a docking station includes the functionality of a port replicator along with additional expansion in the form of enumerable devices or slots and connects to the mobile PC’s PCI bus.

MOBL–0073. Docked mobile PC has the ability to identify the specific model of the dock and to uniquely identify the dock itself

Upon attachment to a docking station, the mobile PC must provide the operating system with the dock’s model number and a unique ID for the dock using the _UID or _BDN ACPI methods. The system vendor may choose the format of the model number and unique dock ID as well as the mechanism for storing and retrieving the data.

For more information on the _UID and _BDN methods, refer to section 6.1.6 of ACPI 1.0b.

MOBL–0074. Docked mobile PC combination meets PC 2001 Mobile requirements

If a mobile PC is shipped with a PC 2001 docking station, the docked mobile PC must meet PC 2001 Mobile requirements.

MOBL–0075. Docking station includes driver support

Drivers for devices in a dock must fully support dynamic loading and unloading, power management, and Plug and Play event messages.

MOBL–0076. Docked mobile PC meets PC 2001 BIOS requirements

The docked mobile PC must meet the PC 2001 BIOS requirement for multiple adapters and multiple monitors. This provides fully operational graphics capabilities in the mobile PC (either the LCD panel or external connector) in the event that a user adds another graphics adapter to the docking station. For more information, see GRPH–0199, "Onboard graphics devices can be used as a system boot device," in Chapter 8.

MOBL–0077. Pre–PC 2001 docking station requirements

PC 2001 mobile PCs with docking station support do not require new docking station designs. A PC 2001 mobile PC combined with a pre–PC 2001 docking station must meet the following requirements:

  • The user cannot experience resource conflicts.
  • All drivers for earlier docking stations must be made available as necessary to support the preinstalled operating system. OEMs can determine how to distribute these drivers, including methods such as an OEM Web site or the Windows update Web site.

This requirement applies only to drivers for devices that were offered as part of the OEM-supplied configuration; it does not apply to devices added to the docking station by systems integrators or end users.

For example, in order for pre–PC 2001 docking stations to work properly with a PC 2001 mobile PC running Windows 2000, all drivers must be updated to support dynamic loading, Plug and Play, and power management messages. This requirement does not imply that new features must be added, but rather that the docked mobile PC and operating system must have full control over the features in the docking station.

MOBL–0078. Mobile/docking station interface uses ACPI-defined mechanisms

The docked mobile PC must enumerate, configure, and disable non-Plug and Play devices using ACPI-based methods, and implement all notification events and docking control as follows.

The mobile PC’s ACPI BIOS must contain at least the following docking-related functions:

  • DCK_CAP must be set to 1 in the FADT table.
  • _Lxx methods must handle the dock insertion event and the Fail Safe Ejection notification. The _Lxx method must include a Notify to the dock object.
  • ACPI descriptions for ports located on the mobile PC and passed through the docking connector must include an _EJD method.
  • The _WAK method must perform a Notify to the dock object.

A dock object must be specified and must have a device named to represent the docking station, including:

  • _UID method for presenting the dock’s model number and unique ID to the operating system.
  • Optional _BDN method for using the Plug and Play BIOS for dock model number and _UID.
  • _DCK method connecting and disconnecting the docking bus.
  • _STA method for checking the status of the dock.
  • _EJx methods to identify which sleep states docking can occur. If hot docking is implemented, the _EJ0 control method must not return until the ejection is complete, as stated in ACPI 1.0b section 6.3.2.

For additional information on ACPI docking implementation, refer to ACPI 1.0b and "ACPI Docking for Windows 2000," listed in "Mobile References."

Removable ATA devices in the docking station and in the mobile PC are required to report changes using ACPI-based methods.

Note: Under Windows 2000, drive letter assignments do not change when drives are added or removed by way of a docking event. That is, all drives in the mobile PC retain their originally assigned drive letters. Note this difference from Windows Me.

MOBL–0079. Docking station supports warm docking

Attaching or ejecting a mobile PC from a docking station must not require powering off the system and must not require a system reboot.

The mobile PC’s ACPI BIOS must contain one or more _EJx methods to inform the operating system of which sleep states are supported for docking operations.

For more information on the _EJx methods for Windows 2000, refer to Section 6.3.2.I of ACPI 1.0b and to "ACPI Docking for Windows 2000," listed in "Mobile References."

MOBL–0080. Docking system supports fail-safe docking

The system must provide a mechanism for notifying the operating system before undocking a mobile PC. The mechanism, in combination with operating system capabilities and methods defined in Sections 5 and 6 of ACPI 1.0b, must perform the following:

  • The user can initiate undocking through Windows-based software choices and through an eject notification button on the docking station or the mobile PC.
  • The eject notification button or software choice sends a signal to the operating system so that the user is warned if the system is in danger of losing resources or data.
  • A safe-to-undock indicator is provided so the user knows when it is safe to remove the mobile PC. This indicator can be an LED or any other mechanism chosen by the vendor. If a physical mechanism automatically undocks the mobile PC, the safe-to-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.


Mobile References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

"ACPI Docking for Windows 2000"

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

Advanced Configuration and Power Interface Specification, Revision 1.0b (ACPI 1.0b)

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

PC Card and CardBus Guidelines, Version 1.1

http://www.pcdesguide.org/library/pccard.htm

Smart Battery Charger Specification, Revision 1.1
Smart Battery Data Specification, Revision 1.1
Smart Battery System Manager Specification, Revision 1.0

http://www.sbs-forum.org/specs/

Universal Serial Bus Specification, Revision 1.1

http://www.usb.org/developers/docs.html


Checklist for Mobile

MOBL–0061. Mobile PC performance meets Mobile PC 2001 minimum requirements

MOBL–0062. Mobile PC supports Smart Battery or ACPI Control Method battery

MOBL–0063. Mobile PC includes at least one USB port

MOBL–0064. If implemented, Mobile PC includes compliant IEEE 1394

MOBL–0065. Mobile PC includes CardBus

MOBL–0066. Mobile PC keyboard and pointing device meet PC 2001 Mobile requirements

MOBL–0069. Mobile PC meets PC 2001 Mobile graphics and video requirements

MOBL–0070. Mobile PC includes PC 2001 hard disk as primary boot device

MOBL–0071. Communications capabilities meet Mobile PC 2001 requirements

MOBL–0072. If implemented, CD or DVD drive meets PC 2001 requirements

MOBL–0073. Docked mobile PC has the ability to identify the specific model of the dock and to uniquely identify the dock itself

MOBL–0074. Docked mobile PC combination meets PC 2001 Mobile requirements

MOBL–0075. Docking station includes driver support

MOBL–0076. Docked mobile PC meets PC 2001 BIOS requirements

MOBL–0077. Pre–PC 2001 docking station requirements

MOBL–0078. Mobile/docking station interface uses ACPI-defined mechanisms

MOBL–0079. Docking station supports warm docking

MOBL–0080. Docking system supports fail-safe docking


Part 3 Device Class Subsystem Design Requirements

Chapter 6 Buses and Interfaces

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.


USB

This section presents the requirements for Universal Serial Bus (USB).

Required on all PC 2001 systems, USB provides an expandable, hot-pluggable Plug and Play serial interface that ensures a standard, low-cost socket for adding external peripheral devices ranging from interactive HID devices such as joysticks and pointing devices to isochronous devices such as telephony, audio, and imaging devices. USB allows integration of cascading hubs into desktop devices such as monitors and keyboards.

Any device that plugs into or is connected to a USB port is considered a USB device and must comply with the requirements defined in these requirements. If the device provides the capabilities of one or more functions or it provides a hub to the host, it must comply with the requirements in this chapter.

Unless this chapter defines a specific requirement or exception, all requirements for buses and interfaces apply as presented in Chapter 3, "PC System," Chapter 4, "Workstation," and Chapter 5, "Mobile."

For information about USB BIOS requirements, see "PC 2001 BIOS Requirements" in Chapter 3, "PC System."


USB Core Requirements

This section covers requirements for the USB 1.1 and 2.0 specifications on PC 2001 systems.

USB–0081. USB system hardware and devices comply with USB specifications

USB system hardware and devices, including hubs, must comply with the Universal Serial Bus Specification, Revision 1.1. If a USB hub or device supports USB 2.0, it must comply with the Universal Serial Bus Specification, Revision 2.0.

When a system has more than one host controller, each host controller must provide full bandwidth and isochronous support. Host controllers must be located on the PCI bus (or equivalent) to meet this requirement. The host controller providing USB 1.1 functionality must comply with the specifications for either OpenHCI: Open Host Controller Interface Specification for USB, published by Compaq, Microsoft, and National Semiconductor, or Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1, published by Intel. Information on OHCI and UHCI is listed in "Buses and Interfaces References." Host controllers providing USB 2.0 functionality must comply with the Enhanced Host Controller Interface Specification for Universal Serial Bus 2.0.

USB–0084. USB devices and drivers support maximum flexibility of hardware interface options

Device and driver designs must provide maximum flexibility for interface options so that the operating system or other vendor-supplied resource management tool can coordinate user preferences, allowing multiple devices and applications simultaneously. Minimum requirements consist of the following.

  • USB–0084.1. Devices and drivers provide multiple alternate settings. Devices and drivers must provide multiple alternate settings for each interface where any alternate setting consumes isochronous bandwidth.
  • USB–0084.2. Devices and drivers must not use isochronous bandwidth for alternate setting 0. Devices must consume bandwidth only when they are in use.
USB–0085. USB host controller and devices can wake the system

The USB host controller must support wakeup capabilities from S1, S2, and S3 states. If the system contains multiple USB host controllers, all host controllers integrated on the system board (that is, not add-on cards) are required to support wakeup from S1, S2, and S3.

USB devices and USB client software and drivers must support multiple system suspend and resume cycles into and out of S3.

USB–0086. USB hubs are self-powered

This requirement does not apply for hubs integrated into USB keyboards or into mobile systems. To minimize USB power consumption requirements, bus-powered hubs must provide ports that can be individually power switched.

USB–0087. USB bus, controllers, and devices comply with USB power management requirements

Devices must comply with the power management requirements in the Universal Serial Bus Specification, Revision 1.1. In addition, devices must comply with the Interface Power Management feature in the Universal Serial Bus Common Class Specification, Revision 1.0.

Mobile PC Note

An internal device that connects to a mobile PC using USB must not continually maintain the system when all component parts are on. Such a device will override system power-management settings that control power-saving modes to protect battery life. When any USB device is connected but not active, the driver must allow system power management to suspend the mobile PC.

USB–0088. USB devices and drivers meet requirements in related USB device class specification

A USB device or driver that fits into one of the USB device class definitions must comply with the related USB device class specification.

If a device vendor builds a device in a device class that does not have generic operating system driver support, or if the vendor must exploit additional, unique hardware features in their device, they can create additional WDM minidrivers.

WDM minidrivers are defined in the "Windows 2000 and WDM Drivers" section of the Windows 2000 DDK.

USB–0089. USB devices install without preloading software

A user must not be required to install software before hot-plugging a USB device. Instead, the user must be able to hot-plug the USB device and then load any software in response to operating system detection of the newly attached device.


IEEE 1394

The following requirements expressly require interconnectivity for IEEE 1394-1995 and IEEE 1394a-2000 devices. However, these requirements do not preclude implementations of IEEE P1394b, which has advantages for power management, performance, and integration into low-power systems.

Basic Requirements for IEEE 1394

This section defines the basic PC 2001 requirements for implementing IEEE 1394.

Note: An implementation of IEEE P1394b can meet these requirements.

1394–0090. System implementing IEEE 1394 supports mandatory features in IEEE 1394 standards

Systems that support IEEE 1394 features and interconnectivity that interface to the IEEE 1394 bus must support the industry standards and its amendments as they apply to internal and external devices. Minimum requirements consist of the following.

  • 1394–0090.1. System provides IEEE 1394-1995/1394a interconnectivity

All systems must support the following industry standards and their amendments:

  • IEEE 1394a-2000 amendment to IEEE 1394-1995
  • IEEE 1394-1995 Standard for a High Performance Serial Bus
  • IEEE 1212-2000
  • Serial Bus Protocol 2 (SBP-2)
  • 1394 Trade Association Power Specification (all components)
  • Plug and Play Design Specification for IEEE 1394, Version 1.0c
  • 1394–0090.2. Systems implementing IEEE 1394 internal devices support mandatory features in the IEEE 1394a-2000 or IEEE P1394b amendments to IEEE 1394-1995

A system designer may incorporate one or more internal IEEE 1394 devices, one or more externally accessible IEEE 1394 sockets, or any combination thereof. For example, a system could provide an internal IEEE 1394 DVD device without providing any external interconnect to IEEE 1394. If, however, that same system provides externally accessible IEEE 1394 sockets, support must be provided for connecting an IEEE 1394-1995/1394a device to that socket.

1394–0091. Host controller supports mandatory components of 1394 OHCI 1.1

Host controllers must implement the mandatory features of 1394 Open Host Controller Interface Specification, Revision 1.1, including host notification of a PHY LinkOn event, Dual Buffer Mode enhancements, ack_tardy processing, SCLK failure detection, Skip Processing enhancements, and Block Read Request handling.

PCI Bus Power Management Interface Specification, Revision 1.1, is an implementation option for OHCI 1.1, however, IEEE 1394 host controllers used on PC 2001 systems must provide support for PCI 1.1 Power Management, including power states D0, D1, D2, and D3cold.

1394–0092. Host controller supports minimum peak data rates specified in IEEE 1394 standards

Host controllers must support the highest data rate of the PHY to which they connect.

The host controller’s PHY must support data rates of S100 megabits per second (Mbps), S200 Mbps, and S400 Mbps as specified in IEEE 1394-1995 and IEEE 1394a-2000.

1394–0093. If the IEEE 1394 implementation provides external connectivity, system must use only sockets specified by IEEE 1394-1995 and its amendments

A system that implements externally accessible sockets must provide a method for connecting to devices that only support IEEE 1394-1995 or its amendment, IEEE 1394a-2000.

The connector described in the Device Bay Specification, Version 1.0, is for use inside the PC 2001 system and is not an externally available socket.

Any externally accessible socket must meet all interface specifications of IEEE 1394-1995, 1394a-2000 or IEEE P1394b, as appropriate. This requirement includes, but is not limited to: a) input impedance from the perspective of the pins on the socket looking back into the system, as specified by the IEEE standards, b) signal amplitude, c) sensitivity, and d) jitter.

Minimum acceptable performance of IEEE 1394-1995 and 1394a-2000 sockets can be validated by following the recommendations, test sequences, and test procedures of ANSI/EIA 364-B-90, as specified in the IEEE standards, and comparing results against the electrical and performance requirements contained within the IEEE 1394-1995 and 1394a-2000 standards.

Minimum acceptable performance implementations of non-optical IEEE P1394b sockets can be validated by following the recommendations, test sequences, and test procedures of ANSI/EIA 364-C-94, as specified in the IEEE P1394b standard, and comparing results against the electrical and performance requirements contained within the IEEE P1394b standard.


Requirements for IEEE 1394 Devices

This section summarizes additional requirements for IEEE 1394 peripherals.

1394–0094. Device command protocols conform to standard device class interfaces

Drivers for devices using the SBP-2 protocol must conform to the requirements set in "SBP-2 Support and Windows 2000," listed in "Buses and Interfaces References."

1394–0095. Peak data rates for internal and external devices meet IEEE 1394 requirements

System designers may incorporate IEEE 1394 devices as external, internal, or both. Minimum requirements consist of the following.

  • 1394–0095.1. Internal devices support the standard IEEE 1394a-2000 Amendment data rates. Internal devices support S400-Mbps minimum. A CD-ROM or DVD drive mounted in an externally accessible bay is an example of an internal device.
  • 1394–0095.2. External devices support IEEE 1394a-2000 data transfer rates. External devices that interoperate with a PC and have more than one socket must support S100 Mbps, S200 Mbps, and S400 Mbps data transfer rates. Devices with a single socket may support only S100- or S200-Mbps data transfer rate. An externally mounted CD-ROM or DVD drive is an example of an external device.


Plug and Play for IEEE 1394

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

1394–0096. IEEE 1394 Plug and Play devices demonstrate interoperability with other devices

All devices must support Plug and Play for intended use in both a minimal and an extended bus configuration. A minimal configuration is the minimum number of devices necessary to demonstrate the primary use of the device. An extended configuration has at least two devices added to the minimal configuration. The added devices can be extraneous to the use.

1394–0097. IEEE 1394 devices that initiate peer-to-peer communications provide a remote control interface

All devices capable of initiating peer-to-peer communications that have been designed for use with a PC must provide a remote interface enabling remote control for PC applications that allows a third device, such as a PC or some other device controller, to initiate data transmission between two devices.

For example, two devices communicating on IEEE 1394 use a basic protocol to carry command/status information and the actual data, such as a device driver to handle this communication, with SBP-2 and International Electrotechnical Commission (IEC-61883) as example protocols.


Plug and Play for CSR Space

This section defines the Plug and Play requirements related to Configuration Status Register space.

1394–0098. IEEE 1394 CSR provides unique device identification

The device control and status register (CSR) space must provide configuration information as specified in the IEEE 1212r-2000 standard and applicable IEEE 1394 standards, thus providing Plug and Play device control.

1394–0099. IEEE 1394 device CSR space implements IEEE 1212-2000 format

The CSR space format is specified in the applicable IEEE 1394 standards and the IEEE 1212-2000 standard. The general CSR format is an extensible tree structure enabling a managed environment by providing node-specific and unit-specific information as required for Plug and Play, power management, and isochronous data transfers. The general CSR format also provides for definition of multifunction device units. The bus information block and root directory of the general CSR format are required as specified in CSR table of IEEE 1212-2000.

1394–0100. IEEE 1394 CSR includes a unit directory for each independent device function

A unit directory is required for independent function and control of each device unit. A valid pointer to a unit directory must be provided in the root directory.

1394–0101. Vendor and model leafs support textual descriptor leaf format

Textual descriptors are required for Vendor_ID and Model_ID entries in the CSR space in order to display this information to the user. Each textual descriptor points to a leaf that contains a single character string.

Examples of valid textual descriptors are found in the IEEE 1394 Plug and Play specification.


Power Management for IEEE 1394 Devices

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

1394–0102. Power Manager notified of device power state changes

The host controller and all devices that provide or consume cable power must conform to all components of the 1394 Trade Association Power Specification.

1394–0103. Devices and controllers comply with all components of the 1394 Trade Association Power Specification

The 1394 Trade Association Power Specification provides requirements for implementation of devices that propagate, source, or sink cable power. In addition, mechanisms are defined by which devices consuming cable power may be enabled as well as placed into a variety of power-consuming states.


SCSI

This section presents requirements for the small computer system interface (SCSI), a flexible I/O bus that is used in the design of a wide variety of peripherals, including disk drives, CD drives, tape drives, scanners, and magneto-optical drives. The SCSI host adapter provides 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.

See also "SCSI Storage" in Chapter 12, "Storage."


SCSI Host Adapter Requirements

This section summarizes class specifications and standards for SCSI host adapters.

SCSI–0104. SCSI controller complies with SPI-3

All SCSI controllers must meet the hardware and software design requirements in the SCSI Parallel Interface-3 (SPI-3) standard, listed in "Buses and Interfaces References."

SCSI–0105. PCI-based SCSI host controller supports bus mastering and virtual DMA services

The host controller must support PCI bus mastering. PCI bus mastering must be enabled by default and virtual direct access memory (DMA) services must be supported in the host-adapter option ROM.

SCSI–0106. Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions

SCSI host adapters with boot ROMs must support the current No Emulation mode of the "El Torito"–Bootable CD-ROM Format Specification, Version 1.0 and the BIOS Boot Specification, Version 1.01.

The Int 13h Extensions ensure correct support for high-capacity drives, and consistent drive-letter mapping between real mode and protected mode. 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 the "Layered Block Device Drivers" section of the Windows 98 DDK.

SCSI–0108. Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators

Connectors must comply with the requirements defined in the SCSI-2 standard. The SCSI bus cable must be plugged into shrouded and keyed connectors on the host adapter and devices. For internal configurations, Pin 1 orientation must be designated on one edge of the ribbon cable and also on the keyed connector of the SCSI peripheral device.

Although an external connector is optional, an external connector must be a high-density connector as defined in the SCSI-2 standard.

Clearly label connectors for each SCSI adapter, peripheral, cable, and terminator to indicate the bus type. All external SCSI connectors must display the appropriate SCSI icon defined in the SCSI Parallel Interface (SPI) standard, Annex H, and must display any clarifying abbreviations or acronyms. The following are applicable acronyms and their definitions:

  • DIFF (differential). A signaling method that employs differential drivers and receivers to improve signal-to-noise ratios and increase maximum cable lengths. This method includes both low voltage differential (LVD) and high voltage differential (HVD) types.
  • SE (single-ended). A signaling method that employs drivers and receivers to increase circuit density.
  • LVD (low voltage differential). A signaling method with low signaling voltages supporting higher transfer rates.
  • HVD (high voltage differential). A signaling method with high signaling voltages.
SCSI–0109. Differential devices support DIFFSENS as defined in the SPI-3 Standard

Without DIFFSENS, the differential bus drivers, a single-ended device, or both could be damaged if a single-ended device is connected to a differential bus.

The standard for DIFFSENS is defined in the SPI-3 standards document.

SCSI–0110. Automatic termination circuit and SCSI terminators meet SPI-3 standard

SCSI add-on adapters and on-board controllers must use automatic termination, which 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-2 alternative-2, or Boulay terminators. SCSI termination built onto internal cables must meet SCSI-3 standard.

SCSI–0111. TERMPWR is supplied to the SCSI bus with overcurrent protection

This requirement includes the following two components.

  • SCSI–0111.1. Host adapter supplies TERMPWR. The base requirement for system-board implementations using PCI or another expansion bus is that the host adapter must supply terminator power (TERMPWR) to the SCSI bus. All terminators on the host adapter, as well as those on the internal and external SCSI bus, must be powered from the TERMPWR lines on the SCSI bus.
  • SCSI–0111.2. The circuit that supplies TERMPWR has built-in overcurrent protection. Devices that provide TERMPWR must also provide some means of limiting the current through use of a self-resetting device. For example, a positive-temperature coefficient device or circuit breaker can be designed into the circuit. These devices open during an overcurrent condition and close after the end of the overcurrent condition.

Mobile PC Note

This feature is not required for battery-powered systems that implement the SCSI host adapter as a PC Card device because of battery consumption issues.


Plug and Play for SCSI Host Adapters

This subsection summarizes the Plug and Play requirements for SCSI controllers.

SCSI–0113. SCAM support is disabled by default

If support is present, it must be disabled by default. SCSI Configured AutoMagically (SCAM) is not supported by the Windows family of operating systems; enabling SCAM can cause the system to become unstable or inoperable.

SCSI–0114. SCSI controllers provide multi-initiator support

Multi-initiator support allows two SCSI controllers—each installed in a separate computer system—to coexist on a shared SCSI bus with a set of shared devices. If this capability is supported, the SCSI IDs must be changeable from the default SCSI controller ID of 7, and the boot-time SCSI bus reset operation must be able to be disabled on each controller attached to a shared bus.


ATA and ATAPI

This section presents the requirements for Windows-compatible ATA and ATAPI controllers and peripherals.

The use of ATA in a PC 2001 system is optional. If a system uses ATA, however, all components must comply with the requirements defined in this section.

ATA–0115. ATA/ATAPI controllers comply with ATA/ATAPI-5 standards

All ATA/ATAPI controllers must meet the hardware and software design requirements listed in the AT Attachment with Packet Interface – 5 (ATA/ATAPI-5) standard.

ATA–0116. Bootable ATA controller supports El Torito No Emulation mode

Details are defined in requirement BIOS–0005, "BIOS includes local boot support," in Chapter 3.

ATA–0117. ATA controller supports Int 13h Extensions and Logical Block Addressing

Int 13h Extensions are detailed in SCSI–0106, "Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions."

The system BIOS must support the use of logical block addressing (LBA) for drives with LBA addressable area greater than 16,515,072 sectors, and the system BIOS must use LBA for all read and write operations to the device. The ATA 1226 technical report defines the proper implementation of LBA. Support for drives with capacities greater than 8.4 GB must be provided through the extended services (functions 4xh and greater) of the Int 13h Extensions as defined in Enhanced BIOS Services for Disk Drives [T13-1226DT], Revision 7.

ATA–0118. If implemented, dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels

Although the use of an ATA adapter with more than one channel is optional, if included, dual ATA adapters must be designed so that either channel might be used at any time; the operating system does not have to serialize access between the primary and secondary channel. This requirement means either that the two channels are totally independent or that anything shared. For example, a programmed I/O (PIO) read prefetch buffer is protected by a hardware arbitrator.

Section 5.0 of the BIOS Boot Specification, Version 1.01 defines an implementation for dual asynchronous channels.

A design implementing a single first in/first out (FIFO) that uses a hardware solution to synchronize access to both channels meets this requirement. A request on one channel need not be completed before another request to the other channel can start. A software-based solution is not acceptable.

ATA–0119. Controller supports Ultra DMA (ATA/33)

The programming register set for PCI Integrated Device Electronics (IDE) bus master DMA is defined in ATA/ATAPI-5. ATA drives must comply with ATA-5 to ensure fully featured hardware and Windows-compatible device driver support.

All controllers and ATA hard drive peripherals must support Ultra DMA at transfer rates of 33 MB per second or higher as defined in ATA/ATAPI-5. In addition to improved transfer rates, Ultra DMA also provides error checking for improved robustness over previous ATA implementations. PCI chip sets must implement DMA as defined in ATA-5.

Definitions for the ACPI control methods can be found in Section 10.8 of ACPI 1.0b.

ATA–0120. ATA controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

One edge of the keyed ribbon cable and the keyed connector of the ATA or ATAPI controller and peripheral device must indicate the Pin 1 cable orientation. Designation of the keyed connector must be clearly indicated on or near the connector.

ATA–0121. ATA bus complies with device class power management reference specification

The ATA bus must comply with the Storage Device Class Power Management Reference Specification, Version 1.0a.

ATA–0122. Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA

Discrete ATA and ATAPI controllers that are implemented in mobile docking stations must comply with the PCI IDE Controller Specification, Revision 1.0, for native mode support. This requirement does not apply to controllers that are a part of the mobile PC’s chip set architecture.


PCI

This section presents the PC 2001 requirements for Peripheral Component Interconnect (PCI) host controllers and peripherals.

The PCI architecture has become the most common method used to extend PCs for add-on adapters. Windows Me and Windows 2000 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 Core Requirements

This section summarizes the basic design requirements for PCI.

PCI–0123. All PCI components comply with PCI 2.2

All system-board bus hardware and add-on devices that use PCI must comply with the PCI Local Bus Specification, Revision 2.2 (PCI 2.2).

Bus designs must fully implement all bus requirements on every expansion card connector.

PCI–0057. 66-MHz and 64-bit PCI buses comply with PCI 2.2 requirements

If either 66-MHz or 64-bit PCI buses are implemented in a system, all devices connected to these buses must meet the requirements defined in PCI 2.2.

PCI–0124. PCI-to-PCI bridges comply with the PCI-to-PCI bridge specification

In particular, nonsubtractive decode PCI bridges must implement the standard method to close base address register (BAR) windows as defined in the PCI to PCI Bridge Architecture Specification Rev. 1.1. Setting the BAR to its maximum value and the limit register to zeros effectively closes the I/O or memory window references in that bridge BAR.

PCI–0125. All PCI devices complete memory write transaction (as a target) within specified times

All devices must comply with the Maximum Completion Time requirements in PCI 2.2. Complying with this requirement ensures shorter transaction latencies on PCI, allowing more robust handling of isochronous streams in the system.


Plug and Play for PCI Controllers and Peripherals

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

PCI–0126. PCI device IDs include Subsystem IDs

The Subsystem ID (SID) and SVID fields must comply with the SID requirement in PCI 2.2. For more information, see the white paper, "PCI Device Subsystem IDs and Windows," listed in "Buses and Interfaces References." Appropriate values for the SID and SVID fields are described below.

  • The PCI Special Interest Group assigns valid, nonzero Vendor ID values to member companies. This Vendor ID value must be used to populate the SVID register.
  • The vendor assigns values for the SID register. To be valid, these values must be nonzero and unique to a subsystem configuration.

Note: For subsystems on system boards that contain a PCI device, the SVID and SID registers must also be loaded with valid nonzero values before the operating system accesses the device. The exception to this requirement is core chip sets.

PCI–0127. PCI interrupt routing is supported using ACPI

The system must provide interrupt routing information using a _PRT object, as defined in Section 6.2.3 of the ACPI 1.0b specification.


Power Management for PCI Controllers and Peripherals

This section lists the specific PCI power management requirements.

PCI–0130. All PCI components comply with PCI Bus Power Management Interface specification

PCI Bus Power Management Interface Specification, Revision 1.1, is the only industry specification that ensures compatibility with the power management capabilities of Windows 2000, which uses PME# as the wakeup signal.

The primary PCI bus controller, PCI-to-PCI bridges, and all PCI add-on devices that implement PME# must comply with the PCI Bus Power Management Interface Specification, Revision 1.1. PCI add-on devices that do not implement PME# must comply with PCI Bus Power Management Interface Specification, Revision 1.0. Minimum requirements consist of the following.

PCI-CardBus Bridges are required to comply with the PC Card Standard, Release 7.

  • PCI–0130.1. All components correctly implement configuration space registers used for power management. This requirement includes correct implementation of the PCI Configuration Space registers used by power management operations, and the appropriate device state definitions.

A PCI function is a set of logic represented by a single Configuration Space. Some examples include PCI-to-PCI bridges, USB host controllers, and IDE controllers. If a function is integrated as part of the core chip set, and thus is not an add-on capable device, it can use ACPI rather than PCI Power Management registers for its power management interface.

  • PCI–0130.2. PCI add-on cards using 3.3Vaux operate correctly. PCI add-on cards that use 3.3Vaux must operate correctly. This applies when the system supports 3.3Vaux to the PCI connectors.

PC add-on cards designed and built exclusively for installation in systems—and which are never sold through retail distribution channels—are not required to supply the static field effect transistor (FET) switches described in section 7.4.4 of PCI Bus Power Management Interface Specification.

A method that PCI add-on cards can use to meet this requirement is described in Section 7.4.4 of PCI Bus Power Management Interface Specification, Revision 1.0.

PCI–0131. System provides support for 3.3Vaux

System support for delivery of 3.3Vaux to the PCI bus must be capable of powering a single PCI slot with 375 mA at 3.3V and it must also be capable of powering each of the other PCI slots on the segment with 20 mA at 3.3V whenever the PCI bus is in the B3 state. See also SYS–0002.1, "System supports S3, S4, and S5 states," in Chapter 3.

Systems must be capable of delivering 375 mA at 3.3V to all PCI slots whenever the PCI bus is in any bus-powered state: B0, B1, or B2.

Mobile PC Note

For mobile PCs, the requirement for delivery of 3.3Vaux is 10 mA at 3.3V because mobile platforms often need to support Small PCI or Mini PCI add-in cards while the bus is in the B3 state.

PCI–0132. PCI-based modem and network adapters support wakeup

PCI-based modem and network adapters must support wakeup as defined in Chapter 13, "Modems," and Chapter 14, "Network Communications."

Note: CardBus-based modem cards are not required to support wakeup.


Bluetooth

Bluetooth technology is designed to be used as a wireless local bus to connect mobile devices over a personal and private connection (in essence, to replace the cables carried by many mobile travelers). Three types of Bluetooth devices are:

  • Host controllers, used to enable PC communication with other devices using Bluetooth wireless technology
  • PC peripherals using Bluetooth wireless technology for communication to the PC
  • Independent devices, such as personal data assistants, which are not within the scope of this design guide


Bluetooth Host Controllers

The following requirements apply to host controllers that are used connect a PC to other Bluetooth devices.

BTH–0396. All Bluetooth Host controllers meet current Bluetooth specifications

Bluetooth Host controllers must meet HCI functional specifications stated in "Part H:1 Bluetooth Host Controller Interface Functional Specification." HCI in the defined transport classes also must meet the corresponding specifications:

  • USB must meet "Part H:2 USB Transport Layer."
  • RS232 must meet "Part H:3 HCI RS232 Transport Layer."
  • Universal Asynchronous Receiver/Transmitters (UARTs) must meet "Part H:4 HCI UART Transport Layer."
BTH–0397. All Bluetooth Host controllers provide Plug and Play and revision information

To minimize the need for new drivers, Bluetooth HCI must do both of the following:

  • Conform to the Plug and Play specifications for the applicable bus, such as USB, PCI, CardBus
  • Support Part H:1 requirements for reporting the revision of the supported HCI specification


Bluetooth PC Peripherals

The following requirements apply to the devices themselves.

BTH–0398. Peripherals equipped with Bluetooth wireless technology provide Plug and Play information

The Bluetooth system defines a Service Discovery Protocol (SDP). Bluetooth PC peripherals must support SDP and support the Bluetooth Specification 1.0.

BTH-0399. Bluetooth peripherals support Windows class driver requirements

Bluetooth peripherals must meet other requirements stated in this guide for the corresponding device types. For example, Bluetooth HID devices, modems, printers, or cameras must meet any applicable corresponding requirements in Chapters 7, 13, 15, or 16 of this design guide respectively.


Buses and Interfaces References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

1394 Open Host Controller Interface Specification, Revision 1.1

http://www.microsoft.com/hwdev/1394/
http://developer.intel.com/technology/1394/download/ohci_11.htm

1394 Trade Association

E-mail: 1394-sig@1394ta.org
http://www.1394ta.org

1394 Trade Association Power Specification Part 1: Cable Power Distribution
1394 Trade Association Power Specification, Part 3: Power State Management

ftp://ftp.p1394pm.org/pub/p1394pm/

Advanced Configuration and Power Interface Specification, Revision 1.0b (ACPI 1.0b)

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

AT Attachment with Packet Interface – 5 (ATA/ATAPI-5)

ftp://fission.dt.wdc.com/pub/standards/x3t13/project/d1321r3.pdf

Other ATA standards
Global Engineering Documents
http://global.ihs.com

BIOS Boot Specification, Version 1.01

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

Bluetooth Special Interest Group (SIG): See Specification of the Bluetooth System

Device Bay Specification, Version 1.0

http://www.device-bay.org

EIA standards

Global Engineering Documents
http://global.ihs.com/

"El Torito" Bootable CD-ROM Format Specification, Version 1.0

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

Enhanced BIOS Services for Disk Drives [T13-1226DT], Revision 7

http://global.ihs.com

Enhanced Host Controller Interface Specification for Universal Serial Bus 2.0

To be published on http://www.usb.org/ when available

IEEE 1212-2000
IEEE 1394a-2000 amendment to IEEE 1394-1995
IEEE 1394-1995 Standard for a High Performance Serial Bus
IEEE P1394b

http://standards.ieee.org/reading/ieee/std/busarch/1394-1995.pdf
http://standards.ieee.org/catalog/ordering.html
http://global.ihs.com

OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

http://www.microsoft.com/hwdev/respec/busspecs.htm
Specification drafts:
http://www.microsoft.com/hwdev/1394/

PC Card Standard, Release 7

http://www.pcmcia.org/bookstore.htm

"PCI Device Subsystem IDs and Windows"

http://www.microsoft.com/hwdev/devdes/pciids.htm

PCI Bus Power Management Interface Specification, Revision 1.1

PCI SIG
Phone: (800) 433-5177
http://www.pcisig.com/developers/specification/

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/developers/docs/

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)
PCI to PCI Bridge Architecture Specification Rev. 1.1

PCI SIG
Phone: (800) 433-5177
For ordering information and document descriptions, see
http://www.pcisig.com/developers/specification/

Plug and Play Design Specification for IEEE 1394, Version 1.0c

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

SBP-2: See Serial Bus Protocol 2.

SBP-2 Support and Windows 2000

http://www.microsoft.com/hwdev/print/sbp2_w2000.htm

SCSI Parallel Interface-3 (SPI-3)

ftp://ftp.t10.org/t10/drafts/spi3/spi3r14.pdf

Serial Bus Protocol 2 (SBP-2)

ANSI NCITS 325-1998
http://web.ansi.org/public/std_info.html

Specification of the Bluetooth System, Volume 1: Core, Version 1.0 B
Specification of the Bluetooth System, Volume 2: Profiles, Version 1.0 B

http://www.bluetooth.com

Storage Device Class Power Management Reference Specification, Version 1.0a
Other device class power management reference specifications

http://www.microsoft.com/hwdev/specs/PMref/PMstore.htm

Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1

http://www2.fm.intel.com/pcd_ae/public/general/specs_ind/USB/uhci_1_1.pdf

Universal Serial Bus Common Class Specification, Revision 1.0
Universal Serial Bus Specification, Revision 1.1
Universal Serial Bus Specification, Revision 2.0

http://www.usb.org/developers/docs.html

Windows Me DDK and Windows 2000 DDK

http://www.microsoft.com/ddk/


Checklist for Buses and Interfaces

USB–0081. USB system hardware and devices comply with USB specifications

USB–0084. USB devices and drivers support maximum flexibility of hardware interface options

USB–0085. USB host controller and devices can wake the system

USB–0086. USB hubs are self-powered

USB–0087. USB bus, controllers, and devices comply with USB power management requirements

USB–0088. USB devices and drivers meet requirements in related USB device class specification

USB–0089. USB devices install without preloading software

1394–0090. System implementing IEEE 1394 supports mandatory features in IEEE 1394 standards

1394–0091. Host controller supports mandatory components of 1394 OHCI 1.1

1394–0092. Host controller supports minimum peak data rates specified in IEEE 1394 standards

1394–0093. If the IEEE 1394 implementation provides external connectivity, system must use only sockets specified by IEEE 1394-1995 and its amendments

1394–0094. Device command protocols conform to standard device class interfaces

1394–0095. Peak data rates for internal and external devices meet IEEE 1394 requirements

1394–0096. IEEE 1394 Plug and Play devices demonstrate interoperability with other devices

1394–0097. IEEE 1394 devices that initiate peer-to-peer communications provide a remote control interface

1394–0098. IEEE 1394 CSR provides unique device identification

1394–0099. IEEE 1394 device CSR space implements IEEE 1212-2000 format

1394–0100. IEEE 1394 CSR includes a unit directory for each independent device function

A unit directory is required for independent function and control of each device unit. A valid pointer to a unit directory must be provided in the root directory.

1394–0101. Vendor and model leafs support textual descriptor leaf format

1394–0102. Power Manager notified of device power state changes

1394–0103. Devices and controllers comply with all components of the 1394 Trade Association Power Specification

SCSI–0104. SCSI controller complies with SPI-3

SCSI–0105. PCI-based SCSI host controller supports bus mastering and virtual DMA services

SCSI–0106. Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions

SCSI–0108. Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators

SCSI–0109. Differential devices support DIFFSENS as defined in the SPI-3 Standard

SCSI–0110. Automatic termination circuit and SCSI terminators meet SPI-3 standard

SCSI–0111. TERMPWR is supplied to the SCSI bus with overcurrent protection

SCSI–0113. SCAM support is disabled by default

SCSI–0114. SCSI controllers provide multi-initiator support

ATA–0115. ATA/ATAPI controllers comply with ATA/ATAPI-5 standards

ATA–0116. Bootable ATA controller supports El Torito No Emulation mode

ATA–0117. ATA controller supports Int 13h Extensions and Logical Block Addressing

ATA–0118. If implemented, dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels

ATA–0119. Controller supports Ultra DMA (ATA/33)

ATA–0120. ATA controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

ATA–0121. ATA bus complies with device class power management reference specification

ATA–0122. Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA

PCI–0123. All PCI components comply with PCI 2.2

PCI–0057. 66-MHz and 64-bit PCI buses comply with PCI 2.2 requirements

PCI–0124. PCI-to-PCI bridges comply with the PCI-to-PCI bridge specification

PCI–0125. All PCI devices complete memory write transaction (as a target) within specified times

PCI–0126. PCI device IDs include Subsystem IDs

PCI–0127. PCI interrupt routing is supported using ACPI

PCI–0130. All PCI components comply with PCI Bus Power Management Interface specification

PCI–0131. System provides support for 3.3Vaux

PCI–0132. PCI-based modem and network adapters support wakeup

BTH–0396. All Bluetooth Host controllers meet current Bluetooth specifications

BTH–0397. All Bluetooth Host controllers provide Plug and Play and revision information

BTH–0398. Peripherals equipped with Bluetooth wireless technology provide Plug and Play information

BTH-0399. Bluetooth peripherals support Windows class driver requirements


Chapter 7 Input Devices

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter presents requirements for input devices, including legacy ports, wireless capabilities, and input device connectors. It also provides requirements for legacy port replacements such as USB-to-parallel adapters. PC 2001 discourages the use of legacy ports; for additional information about legacy-free and legacy-reduced system requirements, see "Legacy Removal Requirements" in Chapter 3, "PC System."

Legacy Plug and Play requirements are available at Legacy Plug and Play Guidelines , listed in "Input Devices References."

USB support is required for PC 2001 systems, and easy connectivity is important in situations where devices might be interchanged on a regular basis. USB replaces legacy serial and parallel ports as the dominant external connector.

Unless this chapter defines a specific requirement or exception, all requirements for input devices apply as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


General Input Device Requirements

This section summarizes requirements for legacy ports.

INPT–0133. All non-integrated USB human input devices meet USB HID specifications

All USB keyboards, pointing devices, game pads, and their connections included with a PC 2001 system must comply with the Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1, and USB HID Usage Tables, Version 1.1. This is required whether the devices are implemented as wired or wireless.

For HID implementation requirements under the Windows family of operating systems, see the Windows 2000 DDK.

INPT–0134. All PC 2001 input devices support Microsoft DirectInput and work simultaneously

All input devices implemented in a PC 2001 system must have drivers that support Microsoft DirectInput® if they do not use drivers that are built into the operating system. Also, all input devices must be able to correctly provide simultaneous input. Thus, no input device is disabled automatically when another input device is in use.

Note: The built-in drivers provided with Windows Me and Windows 2000 meet this requirement.

For information about implementing drivers that support simultaneous use of devices, see the Microsoft DirectInput DDK provided with the Windows 98 DDK, listed in "Input Devices References."

INPT–0135. Devices use USB or external bus connections rather than legacy serial or parallel ports

Although legacy ports can be provided on a PC 2001 legacy-reduced system, no devices that use these ports can be provided with a system. Legacy ports include the serial and parallel ports on the PC. A legacy serial port cannot serve as a mouse, modem, PIN data-entry keyboard, or smart card reader connection. The FDC bus cannot be used for removable media other than standard floppy media. It is allowable to externally expose the FDC bus through the parallel port connector. For a complete list of legacy-related requirements, see "Legacy Removal Requirements" in Chapter 3.

INPT–0136. Serial port adapter meets device class specifications for its bus

As required for all PC 2001 devices, a serial port implementation must meet the specific device class requirements for that bus. An example of a serial port adapter is a USB-to-serial adapter. Such an implementation must comply with all related USB specifications, including:

  • Universal Serial Bus Specification, Revision 1.1 (also known as the USB core specification).
  • Universal Serial Bus Class Definitions for Communication Devices, Version 1.0.

The "Standard Serial Interface Circuit Emulation" appendix in the Universal Serial Bus Class Definitions for Communication Devices specifically addresses serial-port compatibility.

INPT–0137. If implemented, legacy serial port is implemented as 16550A UART or equivalent and supports 115.2K baud

Legacy ports are discouraged for PC 2001 systems, but if implemented, a legacy serial port must comply with legacy the implementation requirements in Legacy Plug and Play Guidelines, listed in "Input Devices References."

INPT–0138. Parallel port meets device class specifications for its bus

As required for all PC 2001 devices, a parallel port implementation that uses a nonlegacy bus must meet the specific device class requirements for that bus.

An example of a parallel port adapter is a USB-to-parallel adapter. Such an implementation must comply with all related USB specifications, including:

  • Universal Serial Bus Specification, Revision 1.1 (also known as the USB core specification).
  • Universal Serial Bus Device Class Definition for Printing Devices, Version 1.0.
INPT–0139. If a legacy parallel port is implemented, flexible resource configuration is supported for each parallel port

Legacy ports are discouraged for PC 2001 systems, but if implemented, a legacy parallel port must comply with legacy implementation requirements in Legacy Plug and Play Guidelines , listed in "Input Devices References."

INPT–0140. Daisy-chained legacy parallel port device is Plug and Play capable

Daisy-chained legacy parallel port devices must be Plug and Play capable. The daisy-chained parallel port device must be capable of answering Plug and Play requests from the host.

All pass-through devices must comply with IEEE 1284.3 because of end-of-chain issues with IEEE 1284 and IEEE 1284.3. Support for parallel ports and daisy-chained devices is provided in the "High-Level Operation of Parclass and Parport" section of the Windows 2000 DDK, listed in "Input Devices References."

INPT–0141. Pointing-device connection meets requirements for its bus class

For implementation requirements for legacy devices such as PS/2-compatible mouse devices, see Legacy Plug and Play Guidelines, listed in "Input Devices References."

If a USB connection is used, it must meet the following USB port requirements:

  • Universal Serial Bus Specification, Revision 1.1
  • Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1
  • Minidriver support based on HID class support in the operating system

For information about implementing minidriver support based on HID class support in the operating system, see HID Support Routines for MiniDrivers, in the Windows 2000 DDK, which defines the implementation for both Windows Me and Windows 2000, listed in "Input Devices References."

INPT–0142. Keyboard connection meets requirements for its bus class

Mobile PC Note

For implementation requirements for legacy devices such as PS/2-compatible keyboard devices, see Legacy Plug and Play Guidelines.

If a USB connection is used, it must meet the following requirements:

  • Universal Serial Bus Specification, Revision 1.1
  • Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1
  • Minidriver support based on WDM HID class support in the operating system

USB keyboards must support the USB boot device specification. The system BIOS must provide boot support as specified in requirement BIOS–0005.2, "BIOS provides boot support for USB keyboards and hubs," in Chapter 3.

INPT–0143. No interference occurs between multiple keyboards

Mobile PC Note

If the system includes more than one keyboard, there must be no conflicts. For example, a docked mobile PC can have more than one keyboard attached to the system. The keyboard ports on a mobile PC and a docking station must be able to resolve conflicts between the two ports when the mobile PC 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 docked mobile PC, see Chapter 5, "Mobile."

INPT–0144. If implemented, Windows and Application logo keys meet Microsoft requirements

The following are requirements for a keyboard design that includes any Windows logo keys:

  • The keyboard must be developed according to technical requirements in New Key Support for Windows Web page, listed in "Input Devices References."
  • The keyboard must be compatible at the Windows virtual key-code level.
  • The Windows logo key must function as a modifier (Ctrl, Shift, or Alt).
  • The Windows Flag trademark must be clearly distinguished on the key top according to the requirements in Key Support and Keyboard Scan Codes for Windows Web page, listed in "Input Devices References."
INPT–0145. If implemented, Internet browser and multimedia keys use Microsoft APIs

If a keyboard or peripheral implements multimedia or Internet browser keys, they must use the registry keys associated with the WM_APPCOMMAND API to access those functions as described in the Windows 2000 DDK. Registry keys can be programmed using INF files to install special entries as defaults or through a customized interface provided to the user.


Wireless Component Requirements

This section defines requirements for wireless components when they are included in a PC 2001 system, provided either as IR or radio frequency (RF) devices.

For information about requirements for wireless networking devices, see "IrDA Requirements for Network Communications" in Chapter 14, "Network Communications."

INPT–0146. IR device uses NDIS 5.0 miniport driver

An NDIS 5.0 miniport driver is required for all IrDA data devices and wireless network devices. For documentation and sample source code for building a miniport driver, see Chapter 13, "IrDA Miniport NIC Drivers," in the Windows 2000 DDK, listed in "Input Devices References."

INPT–0147. IR device meets IrDA specifications

An IR device must be designed to comply with approved IrDA specifications. If the system is intended to run data transfer applications with other IrDA data devices, it must comply with the IrDA Serial Infrared Data Link Standard Specifications.

If an IrDA Control application is used in a PC 2001 system, it must comply with the IrDA Control Specification.

INPT–0148. System supports standard input speeds of 4 Mbps

Device support is required for FIR input speeds of 4 Mbps for all IrDA Data devices.

INPT–0149. System provides a separate, physically isolated transceiver for each IR protocol supported

This requirement provides for correct implementation for a system that includes IR support for any combination of devices that use the IrDA Data protocol, the IrDA Control protocol, or the universal consumer–IR approach to legacy remote control, each of which use different device signals. The system must also expose each separate transceiver to the operating system.

If multiple IR protocols are supported, controllers must provide separate data connections into the PC using USB. For more information, see Appendix F, "IrDA Control on a USB System," of the IrDA Control Specification, listed in "Input Devices References."

INPT–0150. If a legacy IR port is implemented, flexible resource configuration is supported for each port

A legacy IrDA port must be assigned hardware IDs PNP0510 or PNP0511 (generic IrDA–compatible device) by the BIOS and be enumerated in the ACPI Differentiated Description Table. It must also have a Plug and Play compatible register space as specified in the Plug and Play ISA Specification, Version 1.0a, listed in "Input Devices References."

IMAG–0151. Digital still image device with an IR interface uses the Windows Sockets interface

Windows 2000 does not provide support for IrCOMM-based devices. For imaging devices that include an IR interface, the device manufacturer provides the driver that uses the Windows Sockets interface.

Cameras that comply with Infrared Transfer Picture Specification (IrTran-P), Version 1.0 or later need not provide a Windows Sockets interface-based driver.

Mobile PC Wireless Design

This section defines requirements for wireless devices used with a mobile PC.

MOBL–0152. If implemented in a mobile PC, IR devices support power management

IR capabilities are not required for mobile PCs. IrDA devices must support D0 and D3 states, controlled by methods defined in Section 3.4 of the ACPI 1.0b specification or by the relevant bus-specific methods.


Smart Card Requirements

Smart cards are not required, but if implemented, must comply with the requirements defined in this section. The general device requirements are defined in "General Input Device Requirements."

SMRT–0153. Smart card reader complies with ISO/IEC 7816

A smart card reader must comply with the following specifications:

  • ISO/IEC 7816-1:1998 Identification cards—Integrated circuit(s) cards with contacts—Part 1: Physical characteristics
  • ISO/IEC 7816-2:1999 Identification cards—Integrated circuit(s) cards with contacts—Part 2: Dimensions and location of the contacts
  • ISO/IEC 7816-3:1997 Information technology—Identification cards—Integrated circuit(s) cards with contacts—Part 3: Electronic signals and transmission protocols
  • ISO/IEC 7811-1:1995 Identification Cards—Recording technique—Part 1: Embossing
  • ISO/IEC 7811-3:1995 Identification Cards—Recording technique—Part 3: Location of embossed characters on ID-1 cards
  • ISO/IEC 7813:1995 Identification Cards—Financial transaction cards
  • ISO/IEC 10373:1993 Identification cards—Test methods
  • Interoperability Specification for ICCs and Personal Computer Systems, Version 1.0 (PC/SC Specifications)
SMRT–0154. Smart card reader supports ISO/IEC 7816-3 T=0 and T=1 protocols

A smart card reader must support the asynchronous protocols T=0 and T=1 as described in ISO/IEC 7816-3, either in hardware or in the driver. Both protocols must be supported fully. The smart card reader and the driver must support cards that can handle both protocols.

The following protocol rules apply for the T=1 protocol:

  • A transmission is defined as sending a command to a smart card using one or more T=1 blocks and receiving the corresponding answer using one or more T=1 blocks as defined in ISO/IEC 7816-3.
  • For cards that support Information Field Size integrated circuit Card (IFSC) requests, the first transmission—after a reset of the smart card—must start with an Information Field Size Device (IFSD) request, as defined in ISO/IEC 7816-3, Amendment 1, Section 9.5.1.2.

For cards that do not support an IFSD request (that is, the card replies with an R-Block indicating "Other error"), the transmission must continue with an I-Block.

After a successful RESYNCH request, the transmission must restart from the beginning with the first block with which the transmission originally started.

Support for protocols other than T=0 and T=1 is not required.

SMRT–0156. Smart card reader supports 258-byte packets in T=0 and 259-byte packets in T=1

A smart card reader must support the exchange of the following in a single transmission:

  • 258 byte packets in T=0—that is, 256 data bytes plus the two status words SW1 and SW2.
  • 259 byte packets in T=1—that is, 254 information bytes plus node address, packet control bytes, length, and two Error Detection Code bytes.
SMRT–0155. Smart card reader supports inverse-convention smart cards

A smart card reader must support both inverse and direct convention smart cards either in hardware or in the driver for the operating system.

SMRT–0157. Smart card reader supports a smart card insertion/removal monitor

A smart card reader must be able to detect and report smart card insertions and removals without any user intervention other than removing or inserting the smart card itself. The reader must use an interrupt mechanism to report the smart card insertion or removal to the system. A driver polling method to detect smart card insertion and removals is not an acceptable method for meeting this requirement.

SMRT–0158. Smart card reader supports negotiable and specific modes

To support multiprotocol smart cards and smart cards using higher data rates and higher clock frequencies, the reader must support negotiable and specific modes according to ISO/IEC 7816-3 (1997-12-15), Sections 6 and 7, listed in "Input Devices References."

SMRT–0159. Smart card reader supports 3.5795 MHz minimum clock frequency

A smart card reader must support a minimum clock frequency of 3.5795 MHz.

SMRT–0161. Smart card reader supports the Power Down command

A smart card reader must support the Power Down command to turn off power of a smart card, as defined in ISO/IEC 7816-3 (1997-12-15), Section 5.4, listed in "Input Devices References."

SMRT–0162. If input device implements a PIN data-entry keyboard, it must comply with ISO 13491-1

An input device that uses a keyboard for personal identification number (PIN) entry must comply with ISO 13491-1:1998 Banking—Secure cryptographic devices (retail)—Part 1: Concepts, requirements and evaluation methods, listed in "Input Devices References."


Input Devices References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Advanced Configuration and Power Interface Specification, Revision 1.0b (ACPI 1.0b)

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

"HID Support Routines for MiniDrivers"

http://www.microsoft.com/DDK/

Interoperability Specification for ICCs and Personal Computer Systems Specification, Revision 1.0 (PC/SC Specification)

http://www.pcscworkgroup.com/

IrDA Control Specification (formerly IrBus or the IrDA CIR (Control IR) Standard Final Revision 1.0)
IrDA Serial Infrared Data Link Standard Specifications

http://www.irda.org/standards/specifications.asp

Infrared Transfer Picture Specification (IrTran-P), Version 1.0

http://www.irda.org/standards/specifications.asp

ISO/IEC 7811-1:1995 Identification Cards—Recording technique—Part 1: Embossing

http://www.iso.ch/cate/d14717.html

ISO/IEC 7811-3:1995 Identification Cards—Recording technique—Part 3: Location of embossed characters on ID-1 cards

http://www.iso.ch/cate/d14721.html

ISO/IEC 7813:1995 Identification Cards—Financial transaction cards

http://www.iso.ch/cate/d14731.html

ISO/IEC 7816-1:1998 Identification cards—Integrated circuit(s) cards with contacts—Part 1: Physical characteristics

http://www.iso.ch/cate/d29257.html

ISO/IEC 7816-2:1999 Identification cards—Integrated circuit(s) cards with contacts—Part 2: Dimensions and location of the contacts

http://www.iso.ch/cate/d26536.html

ISO/IEC 7816-3:1997 Information technology—Identification cards—Integrated circuit(s) cards with contacts—Part 3: Electronic signals and transmission protocols

http://www.iso.ch/cate/d14735.html

ISO/IEC 10373:1993 Identification cards—Test methods

http://www.iso.ch/cate/d18434.html

ISO 13491-1:1998 Banking—Secure cryptographic devices (retail)—Part 1: Concepts, requirements and evaluation methods

http://www.iso.ch/cate/d19521.html

Catalog of available standards at:
http://www.iso.ch/cate/cat.html

Key Support and Keyboard Scan Codes for Windows

http://www.microsoft.com/hwdev/desinit/scancode.htm

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/LegacyPnP/

Microsoft DirectInput DDK provided with the Windows 98 DDK

http://www.microsoft.com/ddk/

New Key Support for Windows

http://www.pcdesguide.org/documents/keycode.htm

Plug and Play ISA Specification, Version 1.0a

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

Universal Serial Bus Class Definitions for Communication Devices, Version 1.0
Universal Serial Bus Device Class Definition for Printing Devices, Version 1.09

http://www.usb.org/developers/devclass_docs.html

Universal Serial Bus Specification, Revision 1.1

http://www.usb.org/developers/docs.html

Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1

http://www.usb.org/developers/hidpage.html

USB HID Usage Tables, Version 1.1
Other USB specifications

http://www.usb.org/developers/hidpage.html

Windows 98 DDK and Windows 2000 DDK

http://www.microsoft.com/ddk/


Checklist for Input Devices

INPT–0133. All non-integrated USB human input devices meet USB HID specifications

INPT–0134. All PC 2001 input devices support Microsoft DirectInput and work simultaneously

INPT–0135. Devices use USB or external bus connections rather than legacy serial or parallel ports

INPT–0136. Serial port adapter meets device class specifications for its bus

INPT–0137. If implemented, legacy serial port is implemented as 16550A UART or equivalent and supports 115.2K baud

INPT–0138. Parallel port meets device class specifications for its bus

INPT–0139. If a legacy parallel port is implemented, flexible resource configuration is supported for each parallel port

INPT–0140. Daisy-chained legacy parallel port device is Plug and Play capable

INPT–0141. Pointing-device connection meets requirements for its bus class

INPT–0142. Keyboard connection meets requirements for its bus class

INPT–0143. No interference occurs between multiple keyboards

INPT–0144. If implemented, Windows and Application logo keys meet Microsoft requirements

INPT–0145. If implemented, Internet browser and multimedia keys use Microsoft APIs

INPT–0146. IR device uses NDIS 5.0 miniport driver

INPT–0147. IR device meets IrDA specifications

INPT–0148. System supports standard input speeds of 4 Mbps

INPT–0149. System provides a separate, physically isolated transceiver for each IR protocol supported

INPT–0150. If a legacy IR port is implemented, flexible resource configuration is supported for each port

IMAG–0151. Digital still image device with an IR interface uses the Windows Sockets interface

MOBL–0152. If implemented in a mobile PC, IR devices support power management

SMRT–0153. Smart card reader complies with ISO/IEC 7816

SMRT–0154. Smart card reader supports ISO/IEC 7816-3 T=0 and T=1 protocols

SMRT–0156. Smart card reader supports 258-byte packets in T=0 and 259-byte packets in T=1

SMRT–0155. Smart card reader supports inverse-convention smart cards

SMRT–0157. Smart card reader supports a smart card insertion/removal monitor

SMRT–0158. Smart card reader supports negotiable and specific modes

SMRT–0159. Smart card reader supports 3.5795 MHz minimum clock frequency

SMRT–0161. Smart card reader supports the Power Down command

SMRT–0162. If input device implements a PIN data-entry keyboard, it must comply with ISO 13491-1


Chapter 8 Graphics Adapters

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter presents the requirements for the graphics subsystem. The key design goal is that graphics hardware behaves consistently across a wide range of applications, based on the need of the system to provide fast, high-quality rendering.

Unless this chapter defines a specific requirement or exception, all requirements for graphics adapters apply as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."

For requirements for the internal graphics subsystem on mobile PCs, see "Mobile PC Graphics Design."


Baseline Graphics Features

This section defines the baseline requirements for graphics adapters and the graphics subsystem.

GRPH–0163. Primary graphics adapter uses AGP or another high-speed connection

Accelerated Graphics Port (AGP) requirements are defined in Accelerated Graphics Port Interface Specification, Revision 2.0. PC 2001 requirements are defined in "Requirements for AGP and PCI Graphics Adapters." Specific AGP requirements are as follows:

  • Discrete graphics solutions require the equivalent of AGP 2.X.
  • Integrated graphics solutions require the equivalent of AGP 1.X.

Other buses, such as PCI, may be used for secondary graphics adapters.

GRPH–0164. System provides hardware-accelerated 3-D graphics

Many of the level-of-quality features and enhanced user interface features planned for future versions of Windows rely on Microsoft DirectDraw® and Microsoft Direct3D® being fully implemented in the graphics subsystem. Accordingly, all systems must include DirectX acceleration for 2-D and 3-D as listed in the sections "Hardware Acceleration for 2-D Graphics" and "Hardware Acceleration for 3-D Graphics."

For all systems, 3-D acceleration is based on Direct3D capabilities provided in the operating system.

A system designed as a Windows graphics workstation must include a 3-D accelerator that supports Direct3D and may optionally support OpenGL as well. All hardware-accelerated features of the OpenGL accelerator must be accelerated under Direct3D except for those features not supported by the current released version of Direct3D. OpenGL support can be implemented under Windows as a Mini Client Driver (MCD) or Installable Client Driver (ICD). OpenGL driver support for Windows Me can only be implemented as an ICD.

Implementation details for OpenGL and DirectX are contained in the Windows 98 DDK and Windows 2000 DDK.

GRPH–0165. If Digital Video Interface is implemented, it conforms to DVI specification

DVI is the required interface for connecting monitors with a digital interface. For analog video output, the DVI connector analog feature is the preferred connector for monitors with analog interfaces.

GRPH–0166. Primary graphics adapter works normally with default VGA mode driver

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

GRPH–0167. Adapter and driver support multiple adapters and multiple monitors

System expansion buses that allow graphics adapters such as PCI and AGP can support the simultaneous use of more than one graphics adapter in the system. Multiple-monitor support can be implemented using add-on PCI graphics adapters. The device drivers for each graphics adapter must provide the required support to allow the presence of multiple adapters and multiple monitors.

For more information, see "Multiple-Adapter and Multiple-Monitor Support."

GRPH–0168. Screen resolution and graphics memory capacity meet PC 2001 minimum requirements

All PC 2001 systems must support a minimum resolution of 1024 × 768 × 32 bpp, double buffered in 2-D mode with a 32-bit Z-buffer (defined as 24-bit Z with 8-bit stencil) in 3-D mode.

GRPH–0169. Adapter meets industry specifications for external display interface

Display adapters often implement more than one display interface (for example, VGA and DVI, VGA and National Television System Committee (NTSC), Dual VGA, DVI and NTSC, and so on). Each interface that is implemented must comply with the appropriate industry specifications for that interface as outlined in the following list:

  • Analog VGA. Among other resolutions and refresh rates, the graphics adapter must support the 85 hertz (Hz) ergonomic timings for all required resolutions supported by the monitor up to 1024 × 768. These timings must conform to the Computer Display Monitor Timing Specifications, Version 1, Rev. 0.8, or the VESA Generalized Timing Formula (GTF), Version 1.1. Any higher timings and resolutions must conform to established industry standards. Additionally, in order to provide optimal support for video playback of NTSC broadcasts, the display adapter must support the NTSC (59.94 Hz) refresh rate to assure smooth frame delivery in TV-based video content applications. Phase Alternation Line (PAL) is important in many regions, but there are no specific PC 2001 requirements.
  • Digital Visual Interface (both digital and analog implementations). Devices using DVI must implement the timings as specified in the Digital Visual Interface (DVI), Revision 1.0 specification, provided by the Digital Display Working Group. Support for 85 Hz refresh at specified resolutions is also required to support analog monitors with digital interfaces. VGA Mode 3 typically requires a 70 Hz refresh rate, which is not compatible with liquid crystal displays (LCDs). DVI graphics adapters must support the ability to convert VGA Mode 3 70 Hz outputs to the VESA-equivalent 60 Hz timing standards for these displays. Additionally, in order to provide optimal support for video playback of NTSC broadcasts, the display adapter must support the NTSC refresh rate. PAL is important in many regions, but there are no specific PC 2001 requirements.

Single-chip, multihead devices that support independent displays with different images on each display must be able to meet this requirement on both displays simultaneously and independently unless one of the images is a DVD or MPEG-2 video stream—for example, 85 Hz on the PC monitor while displaying NTSC TV out or DVI at a minimum of 1024 × 768 at 32 bpp. This requirement does not imply that TV out support requires simultaneous VGA or DVI support (see GRPH–0207, "If support for TV or DVD-Video playback is implemented, hardware supports video overlay surface with scaling"), but if such simultaneous support exists, this independence requirement must be met.

Support for interlaced display modes is not required. However, if interlaced modes are implemented and the user selects 1024 × 768 resolution, the graphics adapter must default to a noninterlaced refresh rate with the following exceptions:

  • The attached monitor is not compatible with Display Data Channel (DDC) and the user has not selected a monitor type in the display control panel.
  • The monitor does not support 1024 × 768 noninterlaced mode, as determined from the Extended Display Identification Data (EDID) or monitor registry settings.
GRPH–0170. All supported color depths are enumerated

The driver must enumerate all modes supported so that applications can choose their preferred color depth. The driver must comply with the following guidelines for enumeration:

  • For 16 bpp, the 5:5:5 mode, the 5:6:5 mode, or both must be supported.
  • If only the 5:5:5 mode is supported, the driver must also enumerate this as 16-bpp mode. This is required because some applications only look for 16-bpp support and will run in 8-bit mode if they fail to find a 16-bit mode.
  • If both 5:5:5 and 5:6:5 modes are supported, both modes must be enumerated.

For each color depth supported, color ordering must be implemented as shown in the following list. Color ordering is shown in the following list from the most significant bit (MSB) to the least significant bit (LSB).

Mode | Color ordering
15 bpp | 1 undefined, 5 red, 5 green, 5 blue (URRR RRGG GGGB BBBB)
16 bpp | 5 red, 6 green, 5 blue (RRRR RGGG GGGB BBBB)
24 bpp | 8 red, 8 green, 8 blue (RRRR RRRR GGGG GGGG BBBB BBBB)
32 bpp | 8 alpha, 8 red, 8 green, 8 blue (AAAA AAAA RRRR RRRR GGGG GGGG BBBB BBBB)

GRPH–0171. Graphics operations use relocatable registers only

VGA registers must not be used to perform graphics operations such as bit block transferring (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 system operation never requires the use of base VGA registers, except for system start-up and mode setting.

GRPH–0178. Adapter supports adjustable gamma correction

ICM uses this capability to perform gamma correction for the attached monitor and to allow game applications to switch palettes. This capability also supports transition effects in applications. To provide support for ICM, the graphics adapter gamma must be programmatically adjustable. It is required that downloadable RAM digital-to-analog converter entries be included to perform gamma correction in hardware at 24 bpp or 32 bpp.

This capability must be supported without requiring the use of any VGA resources as defined in GRPH–0171, "Graphics operations use relocatable registers only."

GRPH–0179. Adapter for external display supports Plug and Play monitor detection

The adapter must support the DDC2B host requirements identified in the VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1, which defines the communication channel between the display and host system. The software can use this information to properly manage output to the various displays and to prevent the disabling of television output if no monitor is attached. Devices capable of multihead display must support this feature for all attached monitors.


Multiple-Adapter and Multiple-Monitor Support

This section defines the requirements for multiple-adapter and multiple-monitor support. If a user then adds a second adapter, resources will automatically be available and the operating system can automatically manage multiple display adapters.

Examples of multiple display adapters include:

  • Multiple adapters added to the PC system.
  • A single adapter with a single graphics chip supporting two monitors (single-chip multihead).
  • A single adapter with multiple graphics chips supporting multiple monitors (multihead).
  • Any combination of these scenarios.

Multimonitor support requires multiple-adapter and multiple-monitor compatibility in the BIOS, the graphics adapter, and its driver. This support also allows the system to enable any secondary graphics adapters in VGA mode, thus temporarily disabling that VGA for the previous adapter. For systems with the graphics chip on the system board, see GRPH–0199, "Onboard graphics device can be used as a system boot device." For systems with integrated graphics devices that support AGP slot upgrade capability, see GRPH–0202, "System-board graphics device is not hidden from Plug and play enumeration."

With this support, a single adapter that supports multiple monitors can display independent screen images. The operating system support therefore also assumes that the different displays might have differing X, Y coordinates, resolutions, color depths, refresh rates, and display capabilities.

For technical details about implementing driver support for multiple adapters and multiple monitors, see the Windows 98 DDK and the Windows 2000 DDK.

For additional information about relocatable registers, see GRPH–0171, "Graphics operations use relocatable registers only."

GRPH–0180. Extended resources can be dynamically relocated after system boot

To support Plug and Play for multiple-adapter and multiple-monitor capabilities, all non-VGA standard display resources must be capable of being dynamically relocated after system boot (after POST). Register sets are examples of non-VGA standard display resources, which are also known as extended resources.

GRPH–0181. VGA resources can be disabled by software

A means must be provided to allow a driver to disable its adapter from decoding standard VGA addresses so that the adapter is independent of all other graphics adapters in the system. The adapter must remain fully functional without the VGA addresses.


Hardware Acceleration for 2-D Graphics

This section summarizes requirements related to 2-D graphics features, which can be implemented as hardware acceleration features.

All PC 2001 systems require hardware acceleration for 2-D graphics. Robust DirectDraw support is also required to allow 3-D hardware accelerators to take full advantage of the DirectX architecture.

GRPH–0182. Frame buffer can be accessed asynchronously by the CPU and graphics accelerator

It must be possible for applications to perform direct frame buffer accesses at any time, even while asynchronous accelerator operations are being executed.

GRPH–0183. Hardware supports transparent blter

There is no restriction on source size. A transparent blter can perform a block transfer (blt) with a source key transparent color. This requirement assumes that the blter is asynchronous with the host processor.

GRPH–0184. Hardware provides support to prevent tearing

The hardware must support a mechanism for preventing visible artifacts such as tearing. The mechanism for doing this is at the discretion of the hardware designer, but it must support tear-free capabilities for both full-screen and nonoccluded windowed applications. Only one of two simultaneous displays of the same image on two displays (for example, internal mobile panel and external VGA monitor attached) must meet this requirement. The mechanism to prevent tearing must be performed in synchronization with the vertical blanking interval (VBI).

Except when explicitly requested to do otherwise by an application (via Microsoft DirectDraw), blts must synchronize with the vertical scan line to avoid tearing. The ability to read the current scan line supports blting or writing to the screen without tearing. In some contexts, such as video playback, this support eliminates the need for the secondary overlay buffer. Other exceptions to this requirement may be allowed and are documented in the Windows 2000 DDK.


Hardware Acceleration for 3-D Graphics

This section summarizes requirements related to Microsoft Direct3D technologies that can be implemented as hardware acceleration features. Supporting the items in this section results in improved performance and improved memory use.

GRPH–0185. Hardware supports RGB rasterization

In red-green-blue (RGB) mode under Microsoft Direct3D, shading across a surface is accomplished by independently interpolating all color components. The following capabilities are required for RGB rasterization:

  • GRPH–0185.1. Textures. These include the following:
  • MIP–mapped textures
  • Bilinear, or better filtered textures, rather than point-sampled, with perspective correction
  • GRPH–0185.2. Alpha blending for 3-D graphics. Support for source alpha blending (that is, the blend operation does not require an alpha channel in the render target) and destination alpha blending (that is, the blend operation requires an alpha channel in the render target) is required for all devices. The following table shows the blend modes that must be supported as source and destination factors for alpha blending. All modes must be available in any combination and without dependency on other modes.

Alpha Blending Modes

Blend Mode | Source Factor | Destination Factor
D3DBLEND_BOTHINVSRCALPHA | Required |
D3DBLEND_BOTHSRCALPHA | Required |
D3DBLEND_DESTALPHA | Required | Required
D3DBLEND_DESTCOLOR | Required |
D3DBLEND_INVDESTALPHA | Required | Required
D3DBLEND_INVDESTCOLOR | Required |
D3DBLEND_INVSRCALPHA | Required | Required
D3DBLEND_INVSRCCOLOR |  | Required
D3DBLEND_ONE | Required | Required
D3DBLEND_SRCALPHA | Required | Required
D3DBLEND_SRCALPHASAT | Required |
D3DBLEND_SRCCOLOR |  | Required
D3DBLEND_ZERO | Required | Required

  • GRPH–0185.3. Lighting and fogging. These requirements include the following:
  • Flat and Gouraud shading (that is, constant and linear interpolation of per-vertex diffuse and specular color attributes). The linear interpolation need not be perspective-correct.
  • Specular highlighting through the addition of an RGB specular color, interpolated from per-vertex specular color attributes. The linear interpolation need not be perspective-correct.
  • Fog effects through blending with an arbitrary RGB fog color. The fog blending term is computed on a per-pixel rather than per-vertex basis, and is range-based (range-based fog) or depth-based (pixel fog). See Windows 98 DDK and Windows 2000 DDK for definition and discussion of range-based fog and pixel fog.
  • Driver support for triangle strips and fans.

The Direct3D reference rasterizer provided in DirectX supports all of these capabilities.

GRPH–0186. Hardware supports multitexturing

Multitexturing hardware can apply multiple textures to a polygon. The most common application of multitexturing is with map-based techniques for diffuse lighting and specular reflections.

Implementing this capability requires supporting two or more sets of independent texture coordinates.

The following texture combination operations are required:

  • MODULATERGB: Component-wise multiplication of both texture colors.
  • MODULATELPHA: Multiply colors of one texture by the alpha of the other.
  • ADD: Component-wise addition of both textures.
  • BLEND: Linear combination of textures weighted by a scalar specified in a register or in a polygon alpha.

Multitexturing is used to compute the texture value that participates in the pixel pipeline implemented in Direct3D.

This technique must work in combination with fogging and alpha blending, but is not required to operate at the same time as other advanced filtering. Multipass multitexturing is acceptable; single-pass multitexturing is preferred.

For more information on Windows display and video support, see the Display Technology Web page, listed in "Graphics Adapters References."

GRPH–0187. Hardware supports texture formats

Hardware that implements 3D acceleration must support the following 2D, color texture formats:

  • 16 bpp nonpalletized 1:5:5:5 ARGB
  • 16 bpp nonpalletized 4:4:4:4 ARGB
  • 32 bpp nonpalletized 8:8:8:8 ARGB
GRPH–0188. Hardware complies with texture size limitations

MIP mapping requires that textures of size 1 × 1 be supported. To meet PC 2001 requirements, a 3-D accelerator must support this lower limit on texture size. The texture units must support square and nonsquare power-of-two textures (2n × 2m) up to 1024 × 1024 for all texture operations.

GRPH–0189. Hardware supports Z comparison modes and Direct3D-compatible formats

The 3-D hardware must support 32-bit (24-bit Z and 8-bit stencil), unsigned, lockable Z buffer format and all Z comparison modes.

Hardware that supports Z buffering must support clearing of the Z buffer through the DirectDraw depth-fill blt mechanism. In addition, hardware must support clearing of color, Z buffers, and destination surfaces using this method as well.


Television Output Requirements

This section summarizes requirements for television output capabilities. The requirements in this section apply only if the television output capability is present on a PC 2001 system or on a graphics adapter that supports television output capabilities.

The required support allows an NTSC or PAL television to be used as a primary display surface for the Microsoft Windows family of operating systems and for Windows-based applications. If television output capabilities are provided in a PC 2001 system, support is required for either NTSC or PAL standards.

GRPH–0190. If TV out is implemented, adapter supports overscan/underscan scaling

The television output adapter must be able to correct horizontal and vertical overscan/underscan using hardware scaling. Software must be able to disable and enable this feature.

Mobile PC Note

This requirement does not apply to mobile PC platforms.

GRPH–0191. If TV out is implemented, software supports positioning

Software must be able to program the television output hardware to position the television image in increments of 4 pixels horizontally and 4 scan lines vertically (or finer). The supported range must be at least +/– 40 pixels horizontal and
+/– 20 scan lines vertical.

Mobile PC Note

This requirement does not apply to mobile PC platforms.

GRPH–0192. If TV out is implemented, adapter supports flicker filter

The television output adapter must use multiline (three-tap minimum) hardware filtering techniques for flicker reduction. Enable, disable, and adjust capabilities for the flicker filter must be software controllable.

The TV out capability must be able to accept up to a 1024 × 768 progressive desktop and convert it to an interlaced TV resolution output signal.

GRPH–0193. If TV out is implemented, adapter supports composite video or S-video connectors

Support for composite video or S-video is required.

A dongle with a composite video connector meets this requirement if the dongle ships as part of the TV out implementation.

GRPH–0194. If TV out is implemented, adapter also supports DVI or VGA and television output

A graphics adapter that supports TV out must also support either DVI or VGA or both. This requirement does not apply to systems with integrated displays. The usefulness of a system is greatly enhanced when any combination of outputs can be active concurrently, but concurrent output support is not required.


Plug and Play Requirements for Graphics Adapters

This section summarizes requirements for Plug and Play and other resource- and bus-related capabilities.

GRPH–0195. Display devices do not use VGA BIOS POST to populate PCI SID

System-board and add-on display devices cannot use the VGA BIOS POST routine to populate the SID because the device’s POST code might not be executed until later in the process, after device enumeration occurs. For system-board devices, the system BIOS must populate the SID at power on. Add-on display adapters must provide a method for populating the SID at the point when power is applied and the device is initialized to the state that is ready for POST.

GRPH–0196. System supports conflict resolution, VGA compatibility, and extended registers

When the end user changes or adds a graphics adapter to the system, setting resource assignments must not require changing jumpers or switches on either the card or the system board. The system must be able to automatically relocate the resources used by a graphics adapter on the system board when a graphics adapter expansion card is added to the system. In the event of an irreconcilable conflict with other devices on the system, the system must be able to disable one of the adapters in order to prevent the system from stalling.

The system must support the VGA graphics standard for application compatibility and Windows setup and 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 alternate address, at a minimum, 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 the 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 dynamically disable or relocate VGA resources from C0000h. It must also be possible to re-enable these resources upon system reboot or reset.

For additional related requirements for multiple-monitor support, see "Multiple-Adapter and Multiple-Monitor Support."


BIOS and Option ROM Requirements for Graphics Adapters

This section provides requirements related to BIOS support for graphics adapters.

GRPH–0197. Chips support linear packed-pixel frame buffer, relocatable above 16 MB

Note: For DirectDraw, the graphics adapter’s chip set must support linear access to the frame buffer by the host.

For optimized support with Windows, 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.

GRPH–0198. Option ROM supports DDC2B

The option ROM for the graphics adapter must meet current DDC2B host requirements documented in VESA Display Data Channel (DDC) Standard, Version 3, Level 2B protocol (DDC2B). This standard defines the functions that support the data channel between the graphics adapter and a DDC monitor.

GRPH–0199. Onboard graphics device can be used as a system boot device

Systems that have the graphics chip on the system board, and mobile PCs that are capable of docking in a docking station with PCI slots, must provide a means in the BIOS setup utility to force the system to boot using the onboard graphics device, even when an add-in graphics adapter is installed. This capability is required so the onboard graphics device can be used in a multiple-monitor configuration and for hot undock of a docked mobile system.

For systems with integrated graphics devices that support AGP slot upgrade capability, it is acceptable for the integrated graphics to be disabled automatically. When an add-on card is installed in the AGP slot, integrated devices must support multimonitor.

GRPH–0200. System BIOS supports large frame buffers for graphics adapters

The system BIOS must support large frame-buffer graphics adapters that have up to 256 MB of frame buffers.


Requirements for AGP and PCI Graphics Adapters

This section provides requirements for graphics adapters that use the PCI bus.

GRPH–0201. Graphics device supports IRQ and correctly populates PCI BARs

Proper IRQ support is needed for optimal support of video playback. The display driver queries the actual device to find its register locations and so on. The PCI BARs must be populated correctly for this information to be correct in the registry.

On adapters that do not support an IRQ, the Interrupt Pin Register (3Dh) must be zero (0).

GRPH–0202. System-board graphics device is not hidden from Plug and Play enumeration

The system-board device must disable the PCI device rather than hiding it. Hiding the system-board graphics adapter from the PCI bus when another graphics adapter is detected in the system causes problems for supporting multiple-monitor capabilities.

For systems with integrated graphics devices that support AGP slot upgrade capability, it is acceptable for the integrated graphics to be disabled automatically. When an add-on card is installed in the AGP slot, integrated devices must support multimonitor.


Power Management for Graphics Adapters

This section summarizes the specific power management requirements for graphics adapters.

GRPH–0203. Graphics adapter complies with device class power management reference specification

The Default Device Class Power Management Reference Specification, Version 1.0, 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.

GRPH–0204. Graphics adapter complies with VBE/Core 2.0 extensions for power management

The VESA BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0) specification defines extensions to VGA ROM BIOS services for power management.


Device Drivers and Installation for Graphics Adapters and Video Devices

This section summarizes the requirements for graphics adapters. The requirements in this section are required for all PC 2001 devices.

For additional driver-related requirements for multiple-monitor support, see "Multiple-Adapter and Multiple-Monitor Support."

GRPH–0205. Driver does not bypass any Microsoft-provided system components

The driver must not bypass or patch any Microsoft-provided system components. For Windows, this includes Gdi.exe, Kernel.exe, User.exe, Dibeng.dll, Mmsystem.dll, Ddraw.dll, D3d*.dll, and so on.

For Windows 2000, this requirement applies for all files normally installed in the System32 directory. These files include, but are not limited to, Win32k.sys, Ntoskrnl.exe, Gdi32.dll, User32.dll, and Mcdsrv32.dll.

GRPH–0206. Driver supports dynamic color depth and resolution change

The graphics adapter must operate properly and must not fail when asked by the operating system to change the color depth or resolution. A restart must not be required to accomplish this.


Graphics Subsystem Support for Video

This section presents requirements for the graphics subsystem to support TV or DVD-Video playback.

GRPH-0207. If support for TV or DVD-Video playback is implemented, hardware supports video overlay surface with scaling

It is envisioned that the overlay surface will be implemented using one of the required YUV formats. The graphics adapter must be able to support a minimum of one off-screen video overlay surface that has following characteristics:

  • GRPH–0207.1. Size. Discrete graphics solutions support 1280 × 720 or larger. Mobile platforms and integrated graphics solutions support 720 × 576 or larger.
  • GRPH–0207.2. Screen Resolutions. The video overlay must be fully operative at 640 × 480 and 1024 × 768 and color depths of 16 bpp and 32 bpp.

Mobile PC Note

Mobile platforms must support video overlay up to their native resolution and color depth.

  • GRPH–0207.3. Color formats. The required formats must include the following:
  • YUV 4:2:2 (YUY2): A packed-pixel byte stream for every pixel in the order of Y1, U, Y2, V is required in all overlay surface buffers. No intra-image padding is allowed.

YUV 4:2:0 (YV12): A system-board byte stream for the entire plane in the order of Y plane, V plane, U plane is required in the final overlay surface buffer when double buffering is supported.

  • If double buffering is not supported, YV12 support must be provided in the overlay surface.

Support for the YUV 4:2:0 format is not a requirement if the graphics chip supports on-chip MPEG decoding.

  • GRPH–0207.4. Scaling. When upscaling and downscaling to any size window, the high quality video scaling can occur anywhere between the video input to the chip, on the AGP, PCI, or side port and the video appearing on the screen.

Video scaling must be implemented using the DirectDraw and Microsoft DirectShow® APIs.

For PCs to effectively compete with dedicated consumer electronics video devices, it is necessary to raise the quality of video scaling on the PC. Specifying scaling quality is hard because of the difficulty of quantifying viewer-perceived video quality. These requirements for the quality of the video filter used in the resizing operations are specified:

  • Use bilinear scaling or better; a filter with a minimum of two vertical taps and a minimum of two horizontal taps is required.
  • Video display must be able to shrink or zoom by a variable factor of up to 8:1 in one-pixel increments.
  • The image quality must not be perceptibly degraded when shrinking by factors up to 2:1. Some image degradation is acceptable for the larger shrink ratios.
  • The scaling engine on a PC that is not enabled for digital television (DTV) must be able to accept a standard definition video input (480i or 576i), such as input that might come from a DVD or NTSC source.

For a DTV-enabled PC, the scaling engine must be able to accept an input with a rate of 720p60 (1280 horizontal pixels) and 540p60 (bobbed from 1080i) (1280 horizontal pixels).

For video sources that horizontally exceed 720 pixels, the hardware can upscale vertically using replication and downscale vertically using decimation. For such video sources, playback quality reductions may result as defined in Chapter 9, "Video."

Note: The exception for video sources that horizontally exceed 720 pixels will be removed in a later version of this design guide.

  • Upscaling and downscaling can be done in hardware and software; however, if a part-software solution is implemented, performance must not be degraded. All video requirements in Chapter 9, "Video," that pertain to video quality and CPU utilization apply independent of scaling ratios.

Scaling 4:2:2 or 4:2:0 YUV video must achieve two-pixel granularity.

GRPH–0208. If support for TV or DVD-Video playback is implemented, colorspace conversion can be configured for different color primary standards

Support is required for the ITU-R [BT.601-5] standard, formerly CCIR 601.

GRPH–0395. Hardware supports color keying for video

This is a requirement for video overlays. The hardware must be capable of independently controlling the pixels for compositing the video plane under the graphics plane. This destination color keying must function in all video modes using either or both of the following:

  • A specific color/color range, for example, on 4-bit, 8-bit, 15-bit modes.
  • Additional alpha blending bits in the color plane bits on 16-bit and 32-bit modes.

Color keying allows certain graphics pixels to replace underlying video pixels on a pixel-by-pixel basis. This feature enables video overlays, controls, Windows pop-up menus, dialog boxes, and so on, and it allows for irregular-shaped graphics compositing. Color keying must work simultaneously with any vertical/horizontal scaling active for the underlying video.


Mobile PC Graphics Design

This section defines the specific graphics capabilities for mobile PC 2001 systems.

GRPH–0393. Mobile system meets mobile PC 2001 basic graphics requirements

The basic graphics requirements for mobile PC systems provide support for operating system startup and for running mainstream applications reliably. Additional features must meet additional requirements only on an "if implemented" basis, as defined in the following list.

  • GRPH–0393.1. Mobile system supports display resolution of at least 640 × 480 with 256 colors. Windows requires a display resolution of at least 640 × 480 with 256 colors (8 bpp using a color look-up table) to run properly. Mobile systems that optionally have 3-D support must implement at least 16 bpp color.
  • GRPH–0393.2. Mobile PC system uses PCI or better interconnect. Mobile systems that support 3-D require the performance equivalent of AGP. AGP implementations must support Graphics Address Remapping Table (GART) at a minimum. AGP equivalent implementations must support GART equivalent functionality. PCI implementations are not required to support GART.
  • GRPH–0393.3. Optional 3-D capabilities meet minimum requirements. For mobile systems, 3-D hardware is optional. If 3-D is supported, the mobile PC must meet all 3-D requirements at all supported resolutions up to and including the native display panel resolution of at least 640 × 480, and it must support a color depth of 16 bpp, with the following exceptions:
  • Support of per-pixel fog is not required; however, support of per-vertex fog is required.
  • Support of range-based or table-based fog is not required.
  • Support of 32-bit textures is not required; however, support of 16-bit textures is required.
  • Support of 32-bit Z buffers is not required; however, support of 16-bit Z buffers is required.
  • Support of Stencil buffers is not required.
  • Support of 32 bpp (ARGB 8:8:8:8) is not required.
  • Support of nonsquare power-of-two textures up to 1024(1024 for all textures operations is not required.
  • Support for square, power-of-two textures of sizes up to and including 256(256 is required.
  • GRPH–0393.4. Mobile PC resolution requirements. Resolution and color depth requirements are limited to the capabilities of the integrated display panel when using an integrated panel or a simultaneous external display. Mobile systems that implement a single-chip, multihead configuration must meet the resolution and color depth requirements on the external display only up to the native resolution and color depth of the integrated display panel. Mobile PC systems that provide 3-D hardware acceleration must support a color depth of 16 bpp.
  • GRPH–0393.5. Mobile PC refresh frequency requirements. Mobile systems must support refresh frequencies only up to the native capabilities of the integrated display panel. A mobile system that implements a single-chip, multihead, multimonitor configuration must meet the refresh frequency requirements on the external display only up to the native capabilities of the integrated display panel.
  • GRPH–0393.6. Mobile PC requirements for Plug and Play support for external displays. Mobile PC systems that support external displays must support DDC detection for external displays, as defined in GRPH–0179, "Adapter for external display supports Plug and Play monitor detection," with the following exceptions:
  • Mobile systems do not have to supply +5V to the VGA connector at any time.
  • The DVI connector must supply +5V only during operating system boot, when the user first enables external video, and when the system is actually outputting analog or digital video through the DVI connector.
  • Mobile systems that implement a single-chip, multihead, multimonitor configuration are not required to display the system boot screen on the external display. In this configuration, the expectation is that the external display will be active when the display driver is enabled and the system is configured for multimonitor operation. If the system is configured for operation with only the external display active, the boot screen must be displayed.
  • GRPH–0393.7. Mobile PC multiple-monitor requirements. For mobile PCs, multiple adapter support as described in GRPH–0167, "Adapter and driver support multiple adapters and multiple monitors," is not required unless the system supports single-chip, multihead, multiple-monitor capabilities, or the mobile PC supports a docking station with PCI expansion slots. If the docked mobile PC supports only Mini-PCI, the system is not required to support multiple-monitor requirements.
  • GRPH–0393.8. Mobile BIOS setup utility can force use of system-board graphics. If the mobile system supports docking stations that allow for an additional display adapter (typically via a PCI slot), the manufacturer must provide an option in the system BIOS setup utility to force the system-board graphics device to be used as the boot device. This option always allows a docked mobile system to undock because the VGA device will be in the mobile unit.

See also MON–0235, "Monitor supports sRGB output or an ICC profile is provided," in Chapter 10, which applies for mobile PC flat-panel displays.

GRPH–0394. All mobile systems meet basic interoperability requirements

All mobile systems must meet basic graphics requirements to reliably run Windows and applications. Specifically, the following requirements must be met.

  • GRPH–0166. Primary graphics adapter works normally with default VGA mode driver
  • GRPH–0169. Adapter meets industry specifications for external display interfaces
  • GRPH–0170. All supported color depths are enumerated
  • GRPH–0171. Graphics operations use relocatable registers only
  • GRPH–0178. Adapter supports adjustable gamma correction
  • GRPH–0179. Adapter for external display supports Plug and Play monitor detection
  • GRPH–0180. Extended resources can be dynamically relocated after boot
  • GRPH–0181. VGA resources can be disabled by software. This requirement needs to be met by mobile systems only if multiheaded, multidisplay support exists.
  • GRPH–0182. Frame buffer can be accessed directly by applications
  • GRPH–0183. Hardware supports transparent blter
  • GRPH–0195. Display devices do not use VGA BIOS POST to populate PCI Subsystem ID
  • GRPH–0196. System supports conflict resolution, VGA compatibility, and extended registers
  • GRPH–0197. Chips support linear packed-pixel frame buffer, relocatable above 16 MB
  • GRPH–0198. Option ROM supports DDC2B. For external displays only
  • GRPH–0200. BIOS supports large frame buffers for graphics adapters. For adapters added through docking-station or as PC-card only.
  • GRPH–0203. Graphics adapter complies with device class power management reference specification
  • GRPH–0204. Graphics adapter complies with VBE/Core 2.0 extensions for power management
  • GRPH–0205. Driver does not bypass any Microsoft-provided system components
  • GRPH–0206. Driver supports dynamic color depth and resolution changes


Graphics Adapters References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Accelerated Graphics Port Interface Specification, Revision 2.0

http://developer.intel.com

Computer Display Monitor Timing Specifications, Version 1, Rev. 0.8

http://www.vesa.org/standards.html

Default Device Class Power Management Reference Specification, Version 1.0

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

Digital Visual Interface (DVI), Revision 1.0

http://www.ddwg.org

ITU-R [BT.601-5] (formerly CCIR 601)

ITU (International Telecommunication Union)
E-mail: sales@itu.ch
http://www.itu.int

VESA BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0)
VESA Display Data Channel (DDC) Standard, Version 3
VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1
VESA Generalized Timing Formula (GTF), Version 1.1

http://www.vesa.org/standards.html

Display Technology Web page

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

Windows 98 DDK, Windows 2000 DDK, and DirectX DDK

http://www.microsoft.com/ddk/


Checklist for Graphics Adapters

GRPH–0163. Primary graphics adapter uses AGP or another high-speed connection

GRPH–0164. System provides hardware-accelerated 3-D graphics

GRPH–0165. If Digital Video Interface is implemented, it conforms to DVI specification

GRPH–0166. Primary graphics adapter works normally with default VGA mode driver

GRPH–0167. Adapter and driver support multiple adapters and multiple monitors

GRPH–0168. Screen resolution and graphics memory capacity meet PC 2001 minimum requirements

GRPH–0169. Adapter meets industry specifications for external display interface

GRPH–0170. All supported color depths are enumerated

GRPH–0171. Graphics operations use relocatable registers only

GRPH–0178. Adapter supports adjustable gamma correction

GRPH–0179. Adapter for external display supports Plug and Play monitor detection

GRPH–0180. Extended resources can be dynamically relocated after system boot

GRPH–0181. VGA resources can be disabled by software

GRPH–0182. Frame buffer can be accessed asynchronously by the CPU and graphics accelerator

GRPH–0183. Hardware supports transparent blter

GRPH–0184. Hardware provides support to prevent tearing

GRPH–0185. Hardware supports RGB rasterization

GRPH–0186. Hardware supports multitexturing

GRPH–0187. Hardware supports texture formats

GRPH–0188. Hardware complies with texture size limitations

GRPH–0189. Hardware supports Z comparison modes and Direct3D-compatible formats

GRPH–0190. If TV out is implemented, adapter supports overscan/underscan scaling

GRPH–0191. If TV out is implemented, software supports positioning

GRPH–0192. If TV out is implemented, adapter supports flicker filter

GRPH–0193. If TV out is implemented, adapter supports composite video or S-video connectors

GRPH–0194. If TV out is implemented, adapter also supports DVI or VGA and television output

GRPH–0195. Display devices do not use VGA BIOS POST to populate PCI SID

GRPH–0196. System supports conflict resolution, VGA compatibility, and extended registers

GRPH–0197. Chips support linear packed-pixel frame buffer, relocatable above 16 MB

GRPH–0198. Option ROM supports DDC2B

GRPH–0199. Onboard graphics device can be used as a system boot device

GRPH–0200. System BIOS supports large frame buffers for graphics adapters

GRPH–0201. Graphics device supports IRQ and correctly populates PCI BARs

GRPH–0202. System-board graphics device is not hidden from Plug and Play enumeration

GRPH–0203. Graphics adapter complies with device class power management reference specification

GRPH–0204. Graphics adapter complies with VBE/Core 2.0 extensions for power management

GRPH–0205. Driver does not bypass any Microsoft-provided system components

GRPH–0206. Driver supports dynamic color depth and resolution change

GRPH–0207. If support for TV or DVD-Video playback is implemented, hardware supports video overlay surface with scaling

GRPH–0208. If support for TV or DVD-Video playback is implemented, colorspace conversion can be configured for different color primary standards

GRPH–0395. Hardware supports color keying for video

GRPH–0393. Mobile system meets mobile PC 2001 basic graphics requirements

GRPH–0394. All mobile systems meet basic interoperability requirements


Chapter 9 Video

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter presents the video capability requirements for systems and video receiver and capture components, and related adapters. Systems must be video capable, independent of the inclusion of a video source. For example, systems without DVD drives must still be able to decode MPEG-2. Inclusion of video sources often adds requirements. The following requirements apply for systems that provide DVD-Video playback software and hardware, however shipping of a DVD drive with the system does not imply that a system must pass these requirements.

The emphasis is on interoperability and universal video capabilities. Current broadcast television quality levels guide the quality standard set in this chapter.

Unless this chapter defines a specific requirement or exception, all requirements apply for video as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Baseline Video Features

This section describes basic video features required for all desktop systems.

Mobile PC Note

Mobile PCs must meet these requirements, with the exceptions noted in the mobile section.

Baseline Video Driver Support

This section describes video driver support.

VID–0209. System supports basic video capabilities

For all PC 2001 systems, all graphics and video capabilities must be fully supported at 1024 × 768, 32 bpp mode or better.

VID–0210. Video input, capture, and broadcast device support is based on DirectX foundation class and WDM Stream class or AV Stream class

The driver for any video or tuner/decoder device must use the Microsoft DirectX foundation class to control all video data. In a PC 2001 system, video input devices must use WDM device drivers. For implementation requirements, see the Windows 2000 DDK, listed in "Video References."

If implemented, the MPEG-2 decoder must support the current DirectShow APIs (including DirectX VA) and must support the WDM Stream class driver architecture. The WDM Stream Class or AV Stream Class must be used to support any data streaming. For information, see the DirectX DDK, the Windows Driver Model (WDM) Technology Web page, and the Windows 2000 DDK, listed in "Video References."

VID–0211. All video implementations use DirectShow for video routing and processing

Use the DirectShow environment for all TV or DVD-Video implementations. Typical applications include Transport Stream demultiplexing as well as general MPEG stream routing. Implement drivers using WDM.

While it is not a requirement to use the DirectShow filters provided with the operating system, alternatives must be fully pin compatible (that is, media-type compatible) with the filter APIs provided with the operating system. This will help ensure third-party software application compatibility. For information, see Microsoft DirectShow, listed in "Video References."

VID–0212. Dependent video device is not independently enumerated

If a video device is implemented as a dependent device on a multifunction adapter, it must not be independently enumerated. Instead, its parent must be responsible for installing and loading its driver and for updating the registry on its behalf. See also SYS–0032, "Multifunction device meets PC 2001 device requirements for each device," in Chapter 3.

VID–0213. If non-Microsoft provided DirectShow filters replace any filters included with the operating system, replacements provide a functional and qualitative superset of the replaced modules

Any replacement DirectShow filter must be able to accept the exact same input and output formats provided by the operating system version of the DirectShow filter.

VID–0215. All video implementations meet basic video quality requirements

This requirement defines how to treat, as a whole or by components, all consumer electronics (CE) high quality TV-style video streams. Video implementation must preserve source quality during playback, storage, or processing of the video streams and not adversely affect overall PC performance.

Note: The following solutions are exceptions to this requirement: solutions serviced by nonisochronous video sources (Internet) and solutions that have inherent quality tradeoffs (conferencing cameras, dongles that convert TV-style video into conferencing-style video or still video). Video functions for monitoring purposes only and not for recreational viewing, such as monitor video windows (outputs) of video editing solutions, are also exempt.

Examples of CE quality video sources are NTSC at 720 × 480 × 29.97 frames per second (fps) and PAL at 720 × 576 × 25 fps, both at MPEG 4:2:2. These resolution and frame rates are the standard definition. Other resolution and frame rate combinations may be subject to the same requirements, depending on the source, but only if the source resolution does not exceed the overall pixel rate of the above example (approximately 10.5 megapixels per second).

Video sources with higher pixel rates may cause system performance to degrade. Either dropped frames or reduced image quality, or a combination of both, become acceptable in that case. In the case of time-shifted playback, a slight relaxation is also acceptable. Combined reduction in image quality and frame rate should be commensurate with the excess in input data rate. For example, if the input data rate exceeds the standard definition pixel rate by a factor of four, acceptable performance could allow dropping half of all frames and image quality that is equivalent to having been high-quality scaled by a factor of two horizontally.

Notice that deinterlacing results in twice the display data rate when compared to the source data rate. However, de-interlacing by itself must never be the cause for frame rate or image quality reduction. Only increases in source resolution beyond this standard definition produce a relaxing of the video quality requirements. The requirements include the following.

  • VID–0215.1. TV-style video source frame and field rates must be preserved to memory and to the display. While in steady-state mode, dropped frames may not exceed one per minute.
  • VID–0215.2. TV-style video source resolution must be preserved to memory and to the display.
  • VID–0215.3. TV-style video source quality must be preserved to memory and display. Image entropy consistent with approximately 400 TV lines of vertical resolution must be preserved.
  • VID–0215.4. TV-style video source color information must be preserved to memory and to the display.
  • VID–0215.5. TV-style video source video aspect ratios are preserved and displayed correctly.
  • VID–0215.6. TV-style MPEG-2 video stream playback consumes no more than an additional 45 percent of CPU measured during any given minute.
  • VID–0215.7. TV-style MPEG-2 video stream playback consumes no more than an additional 45 percent of memory, PCI, or AGP bandwidth during any given minute.

Mobile PC Note

Mobile PCs are not required to meet this subrequirement.

  • VID–0215.8. TV-style video stream playback is audio-video synchronized to within 75 ms. Audio-video synchronization drift is corrected without violating the specifics of the frame rate and field rate requirements.
  • VID–0215.9. Video is made available through input or transform filters in the YUY2 color format while maintaining all other baseline video requirements.
  • VID–0215.10. Displayed video that enters the system interlaced but carrying a tag that identifies how the video fields were derived from a progressive source will be deinterlaced using the weave method. Typically, deinterlacing is performed by the graphics subsystem.

This requirement applies only to properly encoded content.

  • VID–0215.11. Displayed video that enters the system interlaced but carries a tag identifying the video source as 24 fps film will be (in combination with weave deinterlacing) played back using a suitable frame rate increasing process such as 3:2 pulldown or better. Typically, deinterlacing is performed by the graphics subsystem.
  • VID–0215.12. Displayed video that enters the system interlaced and carries either no identifying tag or is tagged as interlaced material should be deinterlaced by the graphics subsystem using the bob method or a method superior to the bob method. Deinterlacing also may take place outside of the graphics subsystem.
  • VID–0215.13. When video is displayed on a monitor that is refreshed at a different rate than the field rates and frame rates of the video stream, a consistent frame repeat pattern must be implemented that in itself causes no frames to be dropped.


MPEG-2 Video Playback Requirements

This section presents MPEG-2 playback requirements.

VID–0216. If implemented, all MPEG-2 decoders can accept an MPEG-2 elementary stream

DirectShow provides the selection and demultiplexing of MPEG transport streams and program streams. Stream filtering in hardware can be used to aid this process. DirectShow feeds the appropriate video stream, such as Elementary Stream, to the MPEG decoder. The decoder must be able to take MPEG in that form. Packetized Elementary Stream (PES) format support is also required without reliance on any packet sequence numbering. Decoders must not rely on packet sequence numbering to support applications where packet sequence numbers cannot be created. For example, audio and video might come from separate sources, such as video from disc being synchronized to audio from the Internet.

VID–0217. If implemented, all MPEG transport stream information is available to the central host processor

Video-quality standards must be maintained when streams are being routed via the host processor. MPEG streams can come from a number of sources. DirectShow provides support for selecting the required MPEG streams, demultiplexing them, and feeding them to the appropriate decoder or subsystem. Stream filtering in hardware can be used to aid this process.

When conditional access systems allow it, the transport stream demultiplexing must be performed by the central host processor. In situations where this is not possible, all streams from the original broadcast must be sent to the processor if the processor requests them.

It is not acceptable to implement an "around-the-side" hardware path from the receiver to the MPEG decoder. All digital compressed video streams must be routed using the central host software; this will also make it easier to migrate to video-capable home network environment, where the receiver functions and display functions will typically be in completely separate boxes. It is also necessary for features such as intelligent TV timeshifting.

VID–0340. If implemented, MPEG decoders with motion compensation or Inverse DCT hardware acceleration use the Microsoft-provided DirectX VA API

The required DirectX VA API is documented in the DirectX 8.0 DDK or SDK, listed in "Video References."


DVD-Video Playback Requirements

The following requirements apply for systems that provide DVD-Video playback software and hardware. However, shipping of a DVD drive with the system does not imply that a system needs to pass DVD Video Playback requirements, since a system with a DVD drive is not required to include an MPEG decoder. The goal for DVD and other audio/video (A/V) playback is to ensure that the end-user experience is the same as or better than with a stand-alone DVD player.

VID–0218. If DVD-Video playback is implemented, DVD decoder driver correctly handles media types, time discontinuity, and decode-rate adjustment

Vendor-supplied minidrivers for DVD, MPEG-2, and AC-3 decoders must:

  • Use the correct media types, including validation of all format block fields on connection and on every IPin::QueryAccept message.
  • Query for IMediaSample2 on every received media sample to test for a time discontinuity bit.

It is also acceptable to query on every A/V frame to reduce CPU overhead.

  • Adjust the decode rate in response to IPin::NewSegment () calls for video and subpicture.

For details about APIs, see the DirectShow documentation in the Microsoft Platform SDK, listed in "Video References."

VID–0219. If DVD-Video playback is implemented, DVD decoder supports subpicture compositing and closed captioning

The system must be capable of displaying subpicture data as well as providing closed-captioning support for all such data stored on the disc. This requires YUV offscreen overlay surface support.

Subpicture streams must be supported as defined in DVD Specification, Version 1.0, from Toshiba Corporation.

Note: Alpha blending, or a driver-implemented emulation, is required for static menus.

VID–0220. If DVD-Video playback is implemented, subpicture decoder correctly handles subpicture properties and other functions

The minidriver for the subpicture decoder must be able to:

  • Set the subpicture properties.
  • Turn the subpicture compositing on and off.
  • Set the highlight rect parameters.

For more information, see the Microsoft DirectX SDK and the DirectX information in the Windows 2000 DDK, listed in "Video References."

VID–0221. If DVD-Video playback is implemented, system supports seamless DVD-Video 1.0 navigation

This requirement includes menu navigation, video selection, and language and subpicture track selection in support of the user’s ability to navigate DVD-Video discs.

For any system capable of playing back a DVD-Video title, DVD playback must work with the latest released version of the Microsoft DirectShow Navigator/Splitter filter and other DirectShow test filters to ensure that it conforms to the input and output standards established by the Navigator/Splitter. In particular, it must work with the most recent versions of the following:

  • IdvdGraphBuilder
  • DirectShow DVD Navigator
  • DirectShow Overlay Mixer

The requirement to work with the DirectShow Navigator/Splitter filter is not intended to preclude the use of differentiating product features and enhancements.

VID–0222. If DVD-Video playback is implemented, DVD-Video player provides seamless DVD navigation

All DVD-Video players must navigate chapter breaks seamlessly. This requirement applies even if the underlying elementary streams were created as separate program chain objects. If the navigation calls for a seamless transition, the player must deliver for any legal group of pictures structure, bit rate, or both.

For PC 2001, this player requirement allows independent placement of the layer break position, without regard to chapter navigation. Classically, the layer break is acceptable only during nonseamless transitions.

Although not explicitly allowed in the formal DVD-Video specification, seamless chapter-break transitions span the layer break on some popular DVD features. Therefore, the DVD PC must be able to flawlessly reproducing seamless chapter breaks that are collocated with layer transitions, just as if the layer break weren’t there.

VID–0223. If DVD-Video playback is implemented, All DVD-Video decoders must support Line21 closed-caption data

All DVD-Video decoders must support Line21 closed-captioned data output compatible for use with the DirectShow Line21 decoder filter. In addition to ensuring closed-captioned output for the hearing impaired, it enables applications that use the Line21 channel on DVD as a data channel for non-Line21 data.


VBI Data Delivery Requirements

VID–0224. If implemented, video input or capture device provides raw sampled VBI data to the host

The VBI data must be made available to the host processor to provide enhancement data, Web pages, and information about elements such as video formats and timecode. VBI data must not be affected by any type of video operation, such as cropping, scaling, or frame dropping, that the hardware or the driver is performing on the related video frames.

VID–0225. If implemented, VBI capture oversamples VBI data exactly 4.7 or 5 times

To ensure accurate data reception, data transmitted on all lines of the VBI must be oversampled exactly 4.7 or 5 times the North American Basic Teletext (NABTS) data bit rate (or locale-specific data bit rate). For example, if there are 288 bits of NABTS data on a scan line, approximately 1,354 one-byte samples, plus the necessary margin, must be captured per scan line if 4.7x oversampling is used. This represents the number required for timing tolerances in the NABTS specification and also for timing uncertainties within the capture hardware.

If the hardware cannot provide 4.7 or 5 times oversampled VBI data, the device-specific driver must compensate by resampling, so that 4.7 or 5 times oversampled data are presented to the operating system.


Digital TV Receiver Module Requirements

The requirements in this section apply for any system that implements a digital broadcast subsystem, whether receiving satellite, cable, or terrestrial broadcasts.

Implement receiver modules in the following form factors: Device Bay modules, PCI modules, external modules, or set-top boxes using IEEE 1394. For a receiver module limited to low bit-rate transmissions (less than 5 Mbps), using standard USB is acceptable. Device Bay is a good solution for receivers requiring conditional access systems, but conditional access systems are acceptable with any of the other receiver types.

Digital broadcast and satellite support as defined under these requirements includes all the requirements for hardware decoder capabilities and driver support as defined in this chapter, plus support for the DirectX foundation class, as defined in the Windows 2000 DDK.

VID–0226. If implemented, digital broadcast module can receive all streams contained in the particular transport stream

This receiver module can be a receiver for cable, satellite, or terrestrial, and other digital TV broadcasts. The receiver module must provide data tuning, demodulation, conditional access, and other network-specific functions.

The receiver module must be able to receive both normal broadcast network-related information, such as MPEG video, audio, and program guide information, as well as data-stream information.

The receiver card must provide a way to allow the host to obtain peak cell rate (PCR) and other transport stream fields, such as the discontinuity indicator bit, when the card is performing PES packet building. In this mode, the driver must make the relevant information available to the host. In addition, the receiver card must provide a mode in which the host can obtain full MPEG-2 transport or program stream headers, and data for selected elementary streams.

VID–0227. If implemented, digital broadcast module can receive full bandwidth from each frequency

The receiver module must be able to receive all information transmitted on any tuner or transponder frequency. If demultiplexing is performed on the receiver module, the stream selection and routing must be controlled by software running on the host processor.

VID–0228. If implemented, digital broadcast module can receive a minimum of 32 simultaneous elementary streams

The receiver module must be able to simultaneously receive on the same carrier frequency and send to the host either a transport stream or the complete set of elementary streams and accompanying data. Any receiver doing transport stream splitting, for example, a receiver that provides a proprietary conditional access scheme, must support a minimum of 32 elementary streams being sent to the host. The streams can be of any type, such as 32 simultaneous data streams. These streams, identified by unique service channel IDs or program IDs, are subdivisions of bandwidth on a single tuner frequency.

The receiver module must provide a means for the host processor to control the demultiplexing of the transport stream (containing the multiple data streams) or pass the complete transport stream to the host processor for software demultiplexing. The fundamental requirement is that the resulting MPEG elementary streams are routed by the software running on the host processor.

VID–0229. If implemented, ATSC DTV tuner/demodulator complies with A/53

If an Advanced Television Systems Committee (ATSC) DTV tuner/demodulator is implemented, it must meet the requirements for packetized data transport structure, and modulation and transmission systems as specified in ATSC Digital Television Standard and Amendment No.1 (A/53).


Mobile PC Video Design

This section defines the specific video capabilities for mobile PC 2001 systems. These requirements apply only when the mobile system is running on alternating current (AC) power and is not thermally throttled in any way. No video playback performance requirements apply when the system is running on battery power or in a CPU or bus throttled mode. It is expected that performance—but not functionality—will be compromised when the mobile unit is operating under battery power or in a throttled mode.

MOBL–0231. Mobile system meets mobile PC 2001 basic video requirements

A mobile system is not required to support any motion video capabilities, such as playback. The basic video requirements for such mobile PC systems are defined in the following list:

  • Comply with GRPH–0205, "Driver does not bypass any Microsoft-provided system components," in Chapter 8.
  • Support all related desktop video requirements if the mobile system implements support for optional video capabilities, with the following basic mobile video requirements:

There are no CPU utilization limitations or bus bandwidth restrictions for MPEG-2 playback.

Systems must preserve source frame rates and video quality during video playback to at least 50 percent of desktop requirements.

Mobile PCs are required to support these capabilities only up to their native resolution.


Video References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

ATSC Digital Television Standard and Amendment No.1 (A/53)

National Association of Broadcasters, (800) 368-5644
Society of Motion Picture and Television Engineers, (914) 761-1100
E-mail: mktg@smpte.org
http://www.atsc.org/Standards/stan_rps.html

DVD Specification, Version 1.0

Toshiba Corporation
http://www.toshiba.com

Microsoft DirectShow

http://msdn.microsoft.com/directx/

Windows Driver Model (WDM) Technology Web page

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

Windows 98 DDK, Windows 2000 DDK, and DirectX DDK and SDK

http://msdn.microsoft.com/library/default.asp


Checklist for Video

VID–0209. System supports basic video capabilities

VID–0210. Video input, capture, and broadcast device support is based on DirectX foundation class and WDM Stream class or AV Stream class

VID–0211. All video implementations use DirectShow for video routing and processing

VID–0212. Dependent video device is not independently enumerated

VID–0213. If non-Microsoft provided DirectShow filters replace any filters included with the operating system, replacements provide a functional and qualitative superset of the replaced modules

VID–0215. All video implementations meet basic video quality requirements

VID–0216. If implemented, all MPEG-2 decoders can accept an MPEG-2 elementary stream

VID–0217. If implemented, all MPEG transport stream information is available to the central host processor

VID–0340. If implemented, MPEG decoders with motion compensation or Inverse DCT hardware acceleration use the Microsoft-provided DirectVA API

VID–0218. If DVD-Video playback is implemented, DVD decoder driver correctly handles media types, time discontinuity, and decode-rate adjustment

VID–0219. If DVD-Video playback is implemented, DVD decoder supports subpicture compositing and closed captioning

VID–0220. If DVD-Video playback is implemented, subpicture decoder correctly handles subpicture properties and other functions

VID–0221. If DVD-Video playback is implemented, system supports seamless DVD-Video 1.0 navigation

VID–0222. If DVD-Video playback is implemented, DVD-Video player provides seamless DVD navigation

VID–0223. If DVD-Video playback is implemented, All DVD-Video decoders must support Line21 closed-caption data

VID–0224. If implemented, video input or capture device provides raw sampled VBI data to the host

VID–0225. If implemented, VBI capture oversamples VBI data exactly 4.7 or 5 times

VID–0226. If implemented, digital broadcast module can receive all streams contained in the particular transport stream

VID–0227. If implemented, digital broadcast module can receive full bandwidth from each frequency

VID–0228. If implemented, digital broadcast module can receive a minimum of 32 simultaneous elementary streams

VID–0229. If implemented, ATSC DTV tuner/demodulator complies with A/53

MOBL–0231. Mobile system meets mobile PC 2001 basic video requirements


Chapter 10 Monitors

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

The DVI specification provided by the Digital Display Working Group is the industry standard that allows designers to implement the digital interface with confidence. The large legacy of analog VGA monitors can still be fully supported by systems that meet the requirements presented in this system design guide.

Unless this chapter defines a specific requirement or exception, all requirements for monitors apply as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Basic Monitor Requirements

This section summarizes the basic design requirements common to all monitor types. As with any device, monitors must meet all PC 2001 general device and driver requirements.

Note: Dot-pitch requirements are not specified in these requirements 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. Monitors must provide a sharp and clear image across the full range of resolutions they are intended to support.

MON–0232. Color monitor is E-DDC–compliant with unique EDID identifier

A monitor designed for or included with a PC 2001 system must be compliant with VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1, Level 2B protocols (DDC2B), which defines the communications channel between the display and host system. A monitor must assume multiple I2C-compliant devices exist on the communications bus, and as such, a monitor must not impede the use of the I2C bus in any way. A monitor designed for, or included with, a PC 2001 system must not issue DDC1 transactions.

The monitor also must transmit an EDID structure containing unique ID Manufacturer Name and ID Product Code identifiers, plus all required fields, as defined in Section 3 of VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A.

Mobile PC Note

Mobile and other all-in-one systems are not required to support DDC monitor detection. Displays that are attached and connected using an internal interface are not required to provide EDID data identification. This exception applies to all DDC- and EDID-related requirements in this chapter.

MON–0233. Monitor supports EDID 1.3 data structure

All monitors must support E-EDID by implementing an EDID data structure, which includes the following:

  • Set preferred mode bit for all monitor types.
  • Include timing data for the preferred display mode in Timing #1.

For an LCD or other fixed-format display, this would be the native mode of the panel. For other display types, this is the optimal display mode, which is based on the size and capabilities of the device, and must meet the requirements for refresh rates defined in this chapter.

  • Implement monitor descriptors:
  • Monitor range limits
  • Monitor name
MON–0234. If implemented, LCD monitor or built-in LCD display contains display characterization data

LCD monitors and built-in displays must be optimized for Microsoft ClearType™ and other advanced operating system graphics features being implemented through DirectDraw, Direct3D, DirectShow, and GDI+. This optimization will require additional data regarding the characteristics of the attached display. These characteristics include, but are not limited to:

  • Digital interface (external or internal).
  • Vertical pixel striping orientation in normal orientation (subpixels of the same color aligned in vertical columns).
  • Subpixel format is RGB (ordered left to right). Other formats might be acceptable but must be characterized in EDID.
  • High contrast ratio (minimum of 50:1).
  • No scaling or image filtering applied when display is at native resolution.
  • Detailed gamma data.
  • Additional color information.
  • Monitor rotation capability.

Not all of these characteristics are currently supported in industry standards. These items are noted here for informational purposes and will be documented in appropriate industry specifications and other technical documents as the technologies mature.

The Update on ClearType Font Technology and LCD Displays Web page has additional information about ClearType technologies and is listed in "Monitors References."

MON–0235. Monitors support sRGB output or an ICC profile is provided

The monitor must default either to creating sRGB output or using a vendor-supplied ICC profile.

Windows Me and Windows 2000 support using color profiles that comply with the Specification ICC.1:1998-09 File Format for Color Profiles. The ICM APIs and functionality for Windows 98, Windows Me, and Windows 2000 are defined in the Microsoft Platform SDK, the Windows 98 DDK, Windows Me DDK, and the Windows 2000 DDK. The Color Management and Windows Operating Systems Web page has information about implementing color-matching capabilities for Windows operating systems.

Mobile PC Note

Color-capable devices such as desktop cathode ray tube (CRT) monitors, LCDs on mobile systems, color plasma, and other flat-panel devices that do not default to sRGB output must install and associate with one or more ICC profiles for ICC color management. A monitor color-calibration utility can generate, edit, and install ICC profiles. The sRGB profile is distributed in Windows Me and Windows 2000. Mobile PCs with Double Supertwisted Nematic (DSTN) panels do not require ICC profiles.

The requirements for sRGB are defined in IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB, listed in "Monitors References."

MON–0236. USB functionality does not interfere with monitor INF

If a monitor includes USB functionality from either a HID or USB hub, this functionality must be installed separately from the monitor INF file.

A USB hub included on a monitor must be self-powered or externally powered. It cannot be a bus-powered hub. For more information on USB, see the Universal Serial Bus Specification, Revision 1.1 or later.

Monitor support for Windows is installed using a monitor INF file, such as the INF file defined in the Windows 98 DDK and Windows 2000 DDK.

MON–0237. Monitor meets minimum graphics resolution, based on monitor size

These specific monitor sizes are not required; they show the required pixel format for a given size monitor:

  • 14-inch to 15-inch external monitor or built-in mobile PC display = 800 × 600, noninterlaced
  • 17-inch external monitor or 13-inch to 15-inch external LCD = 1024 × 768, noninterlaced
  • 19-inch and 21-inch external monitor or external LCDs larger than 16 inches = 1280 × 1024, noninterlaced
  • 25-inch large-format monitors = 800 × 600

Note: Sizes for LCDs are the actual viewable image size, rounded to nearest inch. Sizes for CRTs are based on actual CRT size (not visible area) rounded to nearest inch.

MON–0238. CRT-based monitor synchronizes to a new format in less than three seconds

This capability is important because sometimes a change from a high refresh-rate graphics mode to a 60 Hz (or 59.94 Hz variant) mode is necessary to optimize video playback.

When the scanning rate is changed from one of its valid rates to another valid rate, the monitor must resynchronize to the new format and produce a stable picture within three seconds from the graphics adapter becoming stable.

MON–0239. External monitor meets E-DDC and E-EDID standards

E-DDC defines the communications channel between the display and host system, and VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A defines data formats for configuration information. This requirement includes the identification string and other EDID data that the monitor sends to the system.

Use the established standard or (if necessary) detailed timings to indicate the maximum resolution that the monitor supports. Using either the established or the standard timings results in greater flexibility than using detailed timing descriptor blocks.

The following items are particularly critical:

  • EDID content must indicate as much information on the range of the monitor's capabilities as possible. The VESA E-EDID standard clarifies the use of the established and standard timing sections of the EDID to indicate the factory preset modes. If an established or standard timing mode is implemented as a factory preset, then it must be indicated in the appropriate EDID section.

Note: Not all factory preset modes will have a corresponding established or standard timing in the EDID.

  • At least one piece of information must indicate the maximum resolution plus maximum timing at that resolution supported by the monitor. If this indication is not implemented using the established or standards timings, a detailed timing can be used.

To enhance the Plug and Play functionality of monitors, the following monitor descriptor definitions are required, as defined in the E-EDID Release A standard:

  • FD (monitor range). This information is essential for enabling the operating system to calculate the optimal refresh rate for any selected resolution.
  • FC (monitor name). Up to three detailed timing blocks can be used to incorporate the company and model name. These descriptors must be concatenated into a single string, and the blocks must be used in the order in which they are to be concatenated.
  • FF (monitor serial number). If provided, this information is placed in the registry for easy access by asset-management software.
MON–0240. CRT-based monitor supports ergonomic timing standards

The monitor must, at a minimum, support the timings documented in either the VESA Generalized Timing Formula (GTF), Version 1.1 or the Computer Display Monitor Timing Specifications, Version 1, Rev. 0.8. This timing support is required for the resolution specified for each monitor size in MON–0237, "Monitor meets minimum graphics resolution, based on monitor size." Other resolutions and refresh rates may be supported, but for any resolution less than the required resolution, there must be a timing for 75 Hz or better. The standards help ensure a clear, flicker-free display for traditional PC computing.

To support optimal playback of video content, monitors must be able to operate with the 59.94 variant of the 60 Hz VESA timing. All references to 60 Hz timing in this chapter also include the 59.94 variant.


Digital Monitor Requirements

This section describes the specific requirements for digital monitors. For DVI graphics adapter requirements, see GRPH–0169, "Adapter meets industry specifications for external display interface," in Chapter 8.

MON–0241. Digital display interface is DVI compliant

Digital Visual Interface (DVI), Revision 1.0 is the industry standard interface for digital display device interconnect interface. Any system implementing digital monitor output capabilities must implement a DVI-compliant port. Any monitor or display device accepting digital input for display data must implement a DVI-compliant port.

MON–0242. Digital monitor supports hot plug detection

A digital monitor must provide a +5 volt (V) signal to the system within 250 milliseconds (ms) of the system’s assertion of the +5V DDC signal to indicate that the monitor is present and capable of transmitting EDID data. A digital monitor must provide the +5V hot plug detection signal to the system as long as the system is providing the +5V DDC signal to the monitor.

MON–0243. Digital monitor supports VESA VGA Text Mode 3 timings, 640 × 480 and 640 × 400

Digital monitors must support lower resolution scanning formats as defined in the VESA VGA Text Mode 3 standard. Support for both 640 × 480 and 640 × 400 at 60 Hz is required. During system boot and in the event an error displays, Windows uses formats such as 640 × 480, 640 × 400, and "text mode 3."


Analog Monitor Requirements

This section describes the specific requirements for analog monitors.

MON–0244. Analog monitor complies with device-class power management reference specification

Display Device Class Power Management Reference Specification, Version 1.0b 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.


Monitors References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Color Management and Windows Operating Systems Web page

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

Computer Display Monitor Timing Specifications, Version 1, Rev. 0.8

http://www.vesa.org/standards.html

Digital Visual Interface (DVI), Revision 1.0

http://www.ddwg.org

Display Device Class Power Management Reference Specification, Version 1.0b

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

IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB

http://www.iec.ch

Specification ICC.1:1998-09 File Format for Color Profiles

http://www.color.org/ICC-1_1998-09.PDF

Universal Serial Bus Specification, Revision 1.1

http://www.usb.org/developers/docs.html

Update on ClearType Font Technology and LCD Displays Web page

http://www.microsoft.com/hwdev/video/clrtype.htm

VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1
VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A
VESA Extended Display Identification Data (EDID) Standard, Version 3
VESA Generalized Timing Formula (GTF), Version 1.1

Video Electronics Standards Association (VESA)
http://www.vesa.org/standards.html


Checklist for Monitors

MON–0232. Color monitor is E-DDC–compliant with unique EDID identifier

MON–0233. Monitor supports EDID 1.3 data structure

MON–0234. If implemented, LCD monitor or built-in LCD display contains display characterization data

MON–0235. Monitors support sRGB output or an ICC profile is provided

MON–0236. USB functionality does not interfere with monitor INF

MON–0237. Monitor meets minimum graphics resolution, based on monitor size

MON–0238. CRT-based monitor synchronizes to a new format in less than three seconds

MON–0239. External monitor meets E-DDC and E-EDID standards

MON–0240. CRT-based monitor supports ergonomic timing standards

MON–0241. Digital display interface is DVI compliant

MON–0242. Digital monitor supports hot plug detection

MON–0243. Digital monitor supports VESA VGA Text Mode 3 timings, 640 × 480 and 640 × 400

MON–0244. Analog monitor complies with device-class power management reference specification


Chapter 11 Audio

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter provides the hardware and software requirements for PC 2001 audio.

Unless this chapter defines a specific requirement or exception, all requirements apply for audio devices as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Basic Audio Requirements

This section defines the basic hardware requirements for audio on PC 2001 systems. These are system-based requirements, targeted for the entire PC solution, regardless of whether the audio components are separate add-on devices or are built into the system, for example, on the system board, on the audio card or riser, or on the display monitor. These requirements, with the exception of AUD–0323, apply to the design of system audio devices, and not accessory audio peripherals, such as a TV tuner, camera with audio, voice modem, telephone handset, and so on.

AUD–0322. Audio device does not use legacy hardware interfaces for MS-DOS–based applications

If the audio device supports MS-DOS–based applications, it must use operating system–provided or operating system–compatible software emulation of legacy interfaces. Legacy hardware does not meet PC 2001 requirements if the legacy technique allows MS-DOS–based applications to communicate directly with ISA IRQ, DMA, or I/O hardware resources, such as PC/PCI or distributed direct memory access (DDMA).

Appendix A, "Resource Mapping," provides a comprehensive list of legacy and legacy-free assignments.

This requirement also applies to PCI-based audio devices. Whether Windows-based or MS-DOS–based applications are running, the PCI device must not allocate or use ISA IRQs, DMAs, or hard-coded I/O locations. The BIOS and Windows driver must not contain any options to select the use of ISA resources for the audio device.

If a device supports real-mode operation, the only acceptable manner for acquiring ISA resources is to use a real-mode configuration utility.

When running MS-DOS–based applications in a virtual MS-DOS box, the level of legacy compatibility provided by Windows 98 software emulation is comparable to hardware. A comprehensive report on "Windows 98 MS-DOS Box Game Compatibility" is available on the Web site listed in "Audio References."

AUD–0323. PC 2001 audio subsystem is digital ready

PC 2001 audio sources must be available as digital audio streams accessible to the system-wide kernel, that is, they must not rely exclusively on any analog mixing stage between the digital-to-analog converter and the speaker jack as the only means for output. Sources that continue to offer an analog mixing output configuration must also provide the user a configurable digital option.

One model for providing the user such an option is Windows support for CD Music.

The audio sources covered by this requirement, which must be available digitally to USB speakers if attached, are:

  • CD-ROM or DVD
  • TV tuner
  • FM radio
  • Voice modem

Analog Mic and Line In with available analog-to-digital converters (ADCs) are digital ready by definition. Devices for which the operating system supports emulation equivalents, such as hardware accelerated 3-D and MIDI synthesis (Microsoft DirectSound® 3D emulation and the Windows GS Wavetable SW Synth) are excepted.

This requirement assures that all audio content can be made available at both the analog jack and USB port. Elimination of the dependency on analog mixing for output is key to making PC audio easier to configure and use, and it removes a major obstacle for USB audio rendering devices.

AUD–0324. Audio subsystem supports basic data formats

Windows provides software mixing and sample rate conversion, which eliminates the need for hardware to support all possible rates. Therefore, either the audio controller or the audio codec hardware, or both, are only required to support two key rates: 44.1 kilohertz (kHz) and 48 kHz (and, at these two rates, must not depend on sample rate conversion in the driver or operating system).

  • 44.1 kHz is required for efficiency reasons. Most game content uses a sampling rate that is an integer divisor of 44.1 kHz, and CD audio is 44.1 kHz. When the highest input stream is 44.1 kHz and below, the optimal way to operate the audio output is to convert everything to 44.1 kHz and run the audio device at this rate. This conversion provides the best quality and least CPU overhead.
  • 48 kHz is required because it is the prevalent sampling rate for entertainment content, such as DVD movies. When 48 kHz content is present, the operating system switches the audio output to 48 kHz.
  • Support for other rates (8 kHz, 11.025 kHz, 16 kHz, 22.05 kHz, or 32 kHz) in hardware is optional.
AUD–0325. Audio subsystem supports full duplex operation

Full duplex audio is essential to support emerging communications applications such as Internet Protocol (IP) telephony, conferencing, and network gaming. These applications require the audio system to play back and record simultaneously. The following requirements ensure that full duplex operation is available and performance is consistent across implementations.

  • AUD–0325.1. Full duplex operation is supported for all sampling rates supported by the hardware. If the built-in or external audio device includes both input and output capabilities, full duplex operation must be supported for basic formats (16-bit, and 44.1 kHz and 48 kHz), and for all other formats supported by the hardware, for example, at 8 kHz, 11.025 kHz, 16 kHz, 22.05 kHz, or 32 kHz.
  • AUD–0325.2. Independent selection of input and output sample rates. If the built-in or external audio device includes both input and output capabilities, the audio device must support independent selection of input and output sample rates.
  • AUD–0325.3. Sample rates are time-synchronized. If the built-in or external audio device includes both input and output capabilities, the timing relationship between input and output sample rates must remain constant (i.e., no drift). For example, if 8 kHz is selected for both input and output sampling rate, audio hardware must ensure that the sampling rate for input and output is precisely matched.

Further, when input and output sample rates are set to integer ratios, the actual sample rate ratios must match (i.e., no drift). For example, if 8 kHz input sampling rate and 32 kHz output sampling rate are selected, the ratio of actual sampling rates must be precisely 8:32. This requirement can be accomplished by ensuring that both input and output sampling rates are derived from the same clock, and that sample rate divisors are set correctly.

This requirement helps ensure that Acoustic Echo Cancellation (AEC) and Noise Reduction algorithms maintain performance and convergence.

AUD–0326. Audio driver reports sample position for stream synchronization

The driver must be capable of reporting within 1 ms the current position of the buffer being rendered, in relation to the samples given to the codec. This requirement applies for both compressed and uncompressed data.

AUD–0337. Audio meets PC 2001 requirements for WDM driver support

All audio devices must have drivers that use the WDM architecture exclusively. Audio devices must not use VxDs. The manufacturer can either supply a WDM driver with the audio device or rely on a WDM driver provided with Windows Me and Windows 2000.

For information about WDM device driver support for streaming capabilities, see "WDM Kernel Streaming Architecture" and "Kernel Streaming Overview," available on the Web pages indicated in "Audio References."

AUD–0327. If implemented, audio system provides 2-D and 3-D hardware acceleration according to PC 2001 requirements

If the audio hardware provides acceleration for Microsoft DirectSound or DirectSound3D, it must declare its capabilities as follows:

  • The device must accurately report the maximum number of 2-D and 3-D buffers it can play simultaneously on the minimum PC 2001 system. For example, if the device declares that it can support 20 2-D buffers and 30 3-D buffers, it must be able to play 20 2-D buffers or 30 3-D buffers simultaneously.
  • The device must accurately report the number of available 2-D and 3-D buffers. The device must be able to open and play another 2-D or 3-D buffer when the reported number of available voices is greater than 0.
AUD–0328. If implemented, audio system provides DLS acceleration according to PC 2001 requirements

If the audio system provides hardware acceleration of DLS using Microsoft DirectMusic®, the audio system must be able to fulfill all of the capabilities it declares. For example, if the DirectMusic device indicates that it can play 64 voices and provide reverb, then it is required to support both capabilities, simultaneously on the minimum PC 2001 system.


Audio Performance Requirements

This section summarizes the performance requirements for audio on PC 2001 systems.

Several companies joined together to develop Personal Computer Audio Quality Measurements (PCAQM), a standard testing procedure for defining and measuring audio performance. Contributors to PCAQM include Audio Precision, Compaq Computer Corporation, Crystal Semiconductor, Intel Corporation, and Microsoft Corporation. PCAQM definitions and test methods are available from the Personal Computer Audio Quality Measurements Web site listed in "Audio References."

AUD–0329. Audio meets PC 2001 minimum performance requirements

The following table summarizes audio performance requirements for all audio-enabled PC 2001 systems, with the exceptions noted in "Requirements for Mobile PC Audio." These requirements establish a minimum performance level for PCs.

For precise definitions of the terminology used in the following table, please refer to the PCAQM test methodology paper cited earlier in this section.

PC 2001 Audio Minimum Performance Requirements

Feature | Requirement | Value
Full-scale input voltage | FSIV (A-D-PC) line input FSIV (A-D-PC) microphone input | ≥1.0 Vrms ≥100 mVrms
Full-scale output voltage | FSOV (PC-D-A) line output | ≥1.0 Vrms1
Digital playback (PC-D-A) for line output | Frequency response (–3 dB) 44.1 kHz source material 48.0 kHz source material Passband ripple5 Dynamic range THD+N (–3 dB FS) | 20 Hz to 17.6 kHz3 20 Hz to 19.2 kHz3 <+/–0.5 dB ≥80 dB FS A2, 3 ≤–65 dB FS3
Digital playback (PC-D-A) for speaker output | Speaker output with 8-ohm load4 Frequency response (–3 dB) 44.1 kHz source material 48.0 kHz source material Dynamic range THD+N (–3 dB FS) | 100 Hz to 17.6 kHz4 100 Hz to 19.2 kHz4 ≥80 dB FS A2, 3 ≤–65 dB FS3
Digital recording (A-D-PC) for line input | Frequency response 44.1 kHz destination 48.0 kHz destination Passband ripple Dynamic range THD+N (–3 dB FS) | 20 Hz to 17.6 kHz3 20 Hz to 19.2 kHz3 <+/–0.5 dB ≥70 dB FS A2, 3 ≤–60 dB FS3 (input-referenced)
Digital recording (A-D-PC) for microphone input | Frequency response (–3 dB) 22.05 kHz destination Passband ripple Dynamic range THD+N (–3 dB FS) | 100 Hz to 8.8 kHz <+/–0.5 dB ≥70 dB FS A2, 3 ≤–60 dB FS3 (input-referenced)
Line output cross-talk | Channel separation between left and right line out channels (measured at 10 kHz) | ≥60 dB3
Sampling frequency accuracy | Playback Record | 0.1% 0.1%
1 For 3.3V audio codec the required full-scale output voltage (FSOV) for line output is ≥0.7 Vrms. 2 Decibels relative to full scale (FS), measured using "A weighting" filters. 3 For mobile PC, the dynamic range requirements are relaxed by 10 decibel (dB) FS. The total harmonic distortion plus noise (THD+N) requirements are relaxed by 10 dB FS. The required frequency response is 30 Hz to 15 kHz, measured using 3 dB corners. The cross-talk requirements are relaxed by 10 dB FS. 4 Where separate line and speaker outputs are provided. 5 Bandpass for ripple measurements is from 40 Hz to (0.4xFs)/2 Hz.


Requirements for Voice Input

This section discusses incremental requirements for audio subsystem and peripheral devices to support applications requiring voice input on the PC.

These requirements address issues related to microphone input compatibility for voice-input enabled applications such as acoustic echo cancellation, speech recognition, speakerphone telephony, and conferencing.

AUD–0330. Audio subsystem supports AEC reference inputs

Built-in or external audio devices that support full-duplex, stereo playback and record for speakers and microphone must support simultaneous capture of microphone and one or more AEC reference inputs.

At minimum, the audio device must support capture of microphone input in the left channel and a monaural output mix in the right channel, where the monaural output mix is the left and right channels of the main output merged into a single channel. This 1+1 channel interleaved format (similar to stereo) will be referred to as "mic+ref", and can be easily achieved using existing stereo ADCs.

For more information, see Section 6.2 of Audio Codec ’97, Revision 2.1, from Intel Corporation, which describes one possible implementation. This specification is listed in "Audio References."

AUD–0331. If implemented, analog microphone input meets PC 2001 jack and circuit requirements

This requirement enables users with electret or dynamic microphones to connect the device to their PC and achieve consistent results. This requirement also maintains compatibility with the installed base of microphones. For information about headset microphones, see AUD–0332, "If implemented, close-speaking headset microphone meets PC 2001 performance requirements."

If the PC has an analog microphone input, it must meet the following specifications:

  • Three-conductor 1/8-inch (3.5 millimeters) tip/ring/sleeve microphone jack where the microphone signal is on the tip, bias is on the ring, and the sleeve is grounded.

This design is optimized for electret microphones with three-conductor plugs, but will also support dynamic microphones with two-conductor plugs, where the ring and sleeve are shorted together.

  • Minimum AC input impedance between tip and ground: minimum, 4 kilohms.
  • Input voltages of 10–100 millivolts (mV) must deliver full-scale digital input, using software-programmable gain.
  • Maximum 5.5 V with no load, minimum 2.0 V with 0.8 milliampere (mA) load, direct current bias for electret microphones.
  • Minimum bias impedance between bias voltage source and ring: 2 kilohms.
  • AC coupled tip.
AUD–0332. If implemented, close-speaking headset microphone meets PC 2001 performance requirements

The following requirements are for close-speaking headset microphones intended for use in speech-recognition applications.

These requirements are compatible with most of the installed base of sound cards and audio-enabled system boards.

The requirements for a PC 2001 speech-recognition microphone are:

  • Close-speaking headset design positions microphone within 1.5 inches of the corner of the speaker’s mouth.
  • FSOV: 100 mV (0 dB FS).
  • Microphone connector meets requirements stated in the requirement
    AUD–0331, "If implemented, analog microphone input meets PC 2001 jack and circuit requirements."
  • Operating bias voltage from 2.0–5.0 volts direct current (VDC) with a maximum current drain of 0.8 mA.
  • Capable of sustaining a maximum voltage of 10 VDC on tip or ring without damage.
  • Frequency response:
  • ±3 dB from 100 Hz to 10kHz
  • 0 dB at 1 kHz
  • Minimum sensitivity of –44 dB relative to 1 volt per pascal.
  • Maximum 2 percent THD+N 100 Hz to 10 kHz at 94 decibel sound pressure level (dBSPL).
  • Noise cancellation null sensitivity at 90 degrees and 270 degrees, ±10 degrees, with the following minimums:

20 dB at 100 Hz
20 dB at 400 Hz
20 dB at 1000 Hz

20 dB at 4000 Hz
10 dB at 10 kHz

  • Maximum wind noise sensitivity of –65 dB with 0 dB = 1 V (measured with wind speed of 1 meter per second at the 0 degree axis of microphone).
  • Maximum output impedance of 1 kilohm (using a 1-kHz full-scale test tone with 2.0 VDC bias).


Requirements for PCI, USB, and IEEE 1394 Audio

This section discusses additional requirements and exceptions for audio devices implemented for PCI, USB, and IEEE 1394.

Audio devices must meet the applicable requirements in Chapter 6, "Buses and Interfaces," unless specified in this chapter.

AUD–0333. PCI device supports initiator, target, and block transfer

For complete implementation details, see PCI 2.2. Full-duplex audio sample transport must be supported using separate PCI bus mastering hardware for playback and capture sample streams.

AUD–0334. PCI device supports efficient audio buffer management

The audio device must be able to fully function when the system can only provide single pages of contiguous memory. In other words, the audio device can require many pages of memory, but must not require the largest block of contiguous memory to exceed one page.

This requirement ensures audio support in docking and dynamic loading scenarios where memory may be fragmented with respect to pages.

The audio device and associated device-specific driver must not introduce unnecessary latency. If the audio driver adds more than 2 milliseconds of computational latency between buffer transfer and queuing for rendering, the driver must provide a programmatic method for a latency sensitive application to temporarily disable the computation.

This requirement helps to ensure that telephony applications closely resemble the performance of a conventional phone and minimizes the possibility that audio and video streams will appear out of synch.

AUD–0335. USB audio meets USB specifications

If USB audio is implemented, the device must comply with Universal Serial Bus Specification, Revision 1.1 and with Universal Serial Bus Device Class Definition for Audio Devices, Release 1.0. This requirement ensures that all Plug and Play requirements are met and that drivers provided with the operating system support this device.

USB audio devices must use an HID to control basic functions. If a USB audio device plans to implement volume adjustment controls, it must employ the HID usages provided on the consumer controls page in the USB HID Usage Tables, Version 1.1 specification and in "Windows Support for HID-based Audio Controls," listed in "Audio References."


Power Management for Audio

This section summarizes the power management requirements for audio components.

AUD–0336. Audio device complies with device class power management reference specification

Audio devices must comply with Audio Device Class Power Management Reference Specification, Version 1.0, which provides definitions of the OnNow device power states (D0–D3) for these devices. The specification also covers the device functionality expected in each power state and the possible wakeup event definitions for the class. The device and driver are required to implement support for power states D0, D2, and D3. Other power states are optional.

Audio devices implemented on the system board must comply fully with ACPI 1.0b.


Requirements for Mobile PC Audio

Mobile audio must meet the requirements for PC 2001 audio as defined earlier in this chapter, with exceptions as defined in this section. These exceptions acknowledge mobile-specific design challenges, such as dual power supplies (battery and AC), low power operation, and smaller form factors.

For mobile PCs, USB plays an especially important role in providing access to higher quality audio output. For more information, see AUD–0323, "PC 2001 audio subsystem is digital ready."

AUD–0338. Audio-enabled mobile PC meets mobile PC 2001 audio performance requirements

For Mobile PCs, the following exceptions and differences are allowed:

  • All dynamic range requirements are relaxed by 10 dB FS A.
  • All THD+N requirements are relaxed by 10 dB FS.
  • The required frequency response (measured at line out) is 30 Hz to 15 kHz, measured using 3 dB corners.
  • All cross-talk requirements are relaxed by 10 dB FS.
AUD–0339. Docked mobile meets PC 2001 speaker selection requirements

The PC 2001 design requirements allow for the audio controller to be implemented on the mobile PC with output capabilities implemented on a docking station. The docking station is not required to implement full desktop audio capabilities, but it can supplement the audio capabilities of the mobile PC. If audio is implemented, the docked mobile PC must meet the requirements for PC 2001 audio as defined in this chapter, with additional requirements as follows:

  • Whether the mobile PC system is docked or not, users must be able to access the highest quality audio output in any given configuration. System vendors can choose to automate the process either in the docking station or the mobile PC to meet this requirement. If speakers are not automatically selected, then the user must be able to select speakers in the mobile PC or docked mobile PC upon docking. However, this requirement must not necessitate users changing the speaker configuration each time they dock and undock.
  • Speakers must be switched off if the headphone jack is used.


Audio References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Advanced Configuration and Power Interface Specification, Revision 1.0b (ACPI 1.0b)

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

Audio Codec ’97, Revision 2.1

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

Audio Device Class Power Management Reference Specification, Version 1.0

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

"Kernel Streaming Overview"

http://www.microsoft.com/ddk/

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/developers/specification

Personal Computer Audio Quality Measurements

By Dr. Steven Harris and Cliff Sanchez, Crystal Semiconductor
http://www.cirrus.com/products/papers/meas/meas.html

Universal Serial Bus Device Class Definition for Audio Devices, Release 1.0

http://www.usb.org/developers/devclass_docs.html

Universal Serial Bus Specification, Revision 1.1

http://www.usb.org/developers/docs.html

USB HID Usage Tables, Version 1.1

http://www.usb.org/developers/hidpage.html

"WDM Kernel Streaming Architecture"

http://www.microsoft.com/hwdev/desinit/csa1.htm

Windows Driver Model (WDM) Technology Web page

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

"Windows 98 MS-DOS Box Game Compatibility"

ftp://download.intel.com/ial/sm/compatibility.pdf

Windows 98 DDK and Windows 2000 DDK (with DirectX DDK)

http://www.microsoft.com/ddk/

"Windows Support for HID-based Audio Controls"

http://www.microsoft.com/hwdev/hid/audctrl.htm


Checklist for Audio

AUD–0322. Audio device does not use legacy hardware interfaces for MS-DOS–based application

AUD–0323. PC 2001 audio subsystem is digital ready

AUD–0324. Audio subsystem supports basic data formats

AUD–0325. Audio subsystem supports full duplex operation

AUD–0326. Audio driver reports sample position for stream synchronization

AUD–0337. Audio meets PC 2001 requirements for WDM driver support

AUD–0327. If implemented, audio system provides 2-D and 3-D hardware acceleration according to PC 2001 requirements

AUD–0328. If implemented, audio system provides DLS acceleration according to PC 2001 requirements

AUD–0329. Audio meets PC 2001 minimum performance requirements

AUD–0330. Audio subsystem supports AEC reference inputs

AUD–0331. If implemented, analog microphone input meets PC 2001 jack and circuit requirements

AUD–0332. If implemented, close-speaking headset microphone meets PC 2001 performance requirements

AUD–0333. PCI device supports initiator, target, and block transfer

AUD–0334. PCI device supports efficient audio buffer management

AUD–0335. USB audio meets USB specifications

AUD–0336. Audio device complies with device class power management reference specification

AUD–0338. Audio-enabled mobile PC meets mobile PC 2001 audio performance requirements

AUD–0339. Docked mobile meets PC 2001 speaker selection requirements


Chapter 12 Storage

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter presents requirements for storage devices and related technologies.

Unless this chapter defines a specific requirement or exception, all requirements for storage devices apply as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Storage Basic Requirements

This section presents the requirements for storage and related peripherals, including DVD devices.

For specific information about implementation details related to storage devices under the Windows Me and Windows 2000 operating systems, see the Storage Technology Web page, listed in "Storage References."

STOR–0341. Storage components and optical devices support bus master capabilities

Hard disk and optical devices (such as CD and DVD devices) must support bus mastering, and bus mastering must be enabled on the host by default. When correctly implemented, bus master support improves performance and Windows-compatible device driver support.

Bus master capabilities must meet the related specification for the particular controller. For example, the programming register set for PCI IDE bus master DMA is defined in the AT Attachment with Packet Interface – 5 (ATA/ATAPI-5), standard. Bus master support is required of optical devices in order to adequately support video playing for DVD and CD-ROM devices.

A DVD drive and controller must support word-aligned, multisegment, bus master DMA transfers. DMA must be enabled by default.

If attached by way of an ATA interface, ATAPI DVD drives and ATA systemboard implementations must support DMA as specified in the ATA/ATAPI-5 standard or ATAPI Removable Rewritable Media Devices (INF-8070i).

STOR–0342. Removable media devices support media status notification

The following list shows the required specifications for implementing media status notification, depending on device type.

Media Status Notification Requirements

Device type | Media status notification implementation
CD and DVD devices | Comply with SCSI Multimedia Commands–2 (MMC-2) standard for Media Status Event Notification.
ATAPI floppy/optical direct access drives | Comply with either MMC-2 standard or INF-8070i version 1.2.
IEEE 1394 storage devices | Comply with Reduced Block Commands (RBC) standard (T10/97-260r0).
ATA and non-ATAPI storage devices | Comply with Media Status Notification Support Specification, Version 1.03.
Other ATA/ATAPI-5 or later devices, including tape drives | If implemented, comply with Media Status Notification Support Specification, Version 1.03, or INF-8070i.
Other types of SCSI removable devices | If implemented, support based on the RBC standard.

STOR–0343. USB storage devices comply with the USB mass storage class specification

All USB storage devices must meet the requirements of the Universal Serial Bus Mass Storage Class Specification Overview, V1.0 Revision. This includes all USB Mass Storage class documents, including Bulk Only, Control/Bulk/Interrupt, Bootability, and UFI Command specifications.


SCSI Storage

This section presents requirements for SCSI storage. See also "SCSI" in Chapter 6, "Buses and Interfaces."

SCSI–0109. Differential devices support DIFFSENS as defined in SPI-3 or later standard

Without DIFFSENS, the differential bus drivers, a single-ended device, or both could be damaged if a single-ended device is connected to a differential bus. The standard for DIFFSENS is defined in Section 5.4.2 of the SPI-3 or later standard.

STOR–0345. External devices use automatic termination or an accessible termination switch

An external SCSI peripheral device must provide automatic termination. At a minimum, a mechanical means must be provided for setting termination and the switch must be accessible to the user without opening the device chassis.

STOR–0346. Devices supports the STOP/START UNIT command as defined in the SBC standard

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 and to see that the operating system responds to appropriate driver calls, the STOP/START UNIT command must be implemented as defined in the SCSI-3 Block Commands (SBC) standard.


ATA and ATAPI Storage

This section defines the requirements for all ATAPI storage devices. See also "ATA and ATAPI" in Chapter 6, "Buses and Interfaces." Discrete ATA/ATAPI-5 controllers in docked mobile PCs must comply with ATA–0122, "Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA" in Chapter 6.

STOR–0347. Peripherals comply with ATA/ATAPI-5

The ATA/ATAPI-5 standard defines hardware and software design requirements for ATAPI devices.

STOR–0348. ATAPI devices support DEVICE RESET command

ATAPI devices must respond to the DEVICE RESET command as defined in the ATA/ATAPI-5 standard, regardless of their internal state. The controller can be reset when the computer is turned on (requests cleared, signature present), but any nondefault mode values must be left in their current state with the device driver (DRV) bit unchanged.

Devices such as hard disk drives that do not implement the PACKET command feature set must not implement the DEVICE RESET command.

STOR–0349. ATA device supports ATA STANDBY command

ATA drives must implement the ATA STANDBY command, as defined in the ATA/ATAPI-5 standard. Information on system power states and transitions can be found in Storage Device Class Power Management Reference Specification, Version 1.0.

STOR–0350. ATA devices support Ultra DMA

All ATA primary storage devices must support Ultra DMA at transfer rates of 33 MB per second or higher as defined in the ATA/ATAPI-5 standard, and as described in ATA–0119, "Controller supports Ultra DMA (ATA/33)," in Chapter 6.


CD and DVD Devices

This section summarizes the requirements for CD peripherals. The device must also meet the general requirements defined in "PC 2001 Design for Storage Components," including STOR–0341, "Storage components and optical devices support bus master capabilities."

STOR–0352. CD or DVD drive is CD-Enhanced compatible

The CD or DVD drive must be able to mount multisession CD-ROM discs, even if track 1 is Red Book audio. CD-Enhanced support must be Blue Book compliant, as defined in CD EXTRA (Enhanced Music CD) Specification, Version 1.0.

STOR–0353. CD or DVD drive supports specified logical and physical CD formats

At a minimum, the CD or DVD drive must be compatible with the following formats for cross-media compatibility, based on compliance with the MultiRead Specifications for CD-ROM, CD-R, CD-R/RW, & DVD-ROM Devices, Revision 1.11:

  • Logical formats: CD Red Book (CD-Audio), Yellow Book (CD-ROM), Orange Book parts II and III (packet writing if recordable), White Book, Blue Book, and Universal Disk Format (UDF) versions 1.5 and 2.0
  • Physical formats: ROM (stamped), and Orange Book part II (CD-R) and part III (CD-RW)

Note: Any ATAPI CD or DVD drive designed to play back CD-I content must return a minimum of two track entries for the READ_TOC (0x43) command. These two track entries must be a track 01 entry and a track 0xAA entry for the lead-out address. Drives that do not comply with this minimum requirement cannot play back CD-I movies.

STOR–0354. CD or DVD drive complies with MMC-2

CD drives must support the hardware and protocols documented in the NCITS specification.

Note: Support for the READ CD-DA command as defined in the MMC-2 standard is required.

STOR–0355. CD drive supports multisession and compatibility forms of the READ_TOC command

Both multisession forms (01b and 10b) and the compatibility form (00b) of the READ_TOC command must be implemented. This provides complete support for CD-ROM multisession capabilities.

For information about ATAPI peripheral support for CD-I content, see requirement STOR–0353, "CD or DVD drive supports specified logical and physical CD formats."

STOR–0356. CD or DVD changer complies with MMC-2

If a CD or DVD changer with a capacity for seven or fewer discs is present, the changer must comply with the MMC-2 standard.

STOR–0357. CD or DVD device supports digital audio extraction with sector accurate reads

The READ_CD command and READ_RAW commands must provide sector-accurate reads, as defined in the MMC-2 standard. Data alignment accuracy must be equivalent to that of data reads. Because of the lack of ECC bytes used for data tracks, the data itself may contain inaccuracies due to physical defects of the media. Furthermore, CD and DVD drives must implement "CD Capabilities and Mechanical Status Page" (2Ah), as defined in the MMC-2 standard. The "CD-DA Commands Supported" and "CD-DA Stream is Accurate" bits must be set and their functionality must be implemented.


DVD Devices

This section summarizes specific requirements for DVD devices. For information about the requirements for DVD-Video and MPEG-2 playback performance, see "DVD-Video Playback Requirements" and "MPEG-2 Video Playback Requirements" in Chapter 9, "Video." For more information about DVD support under Windows Me and Windows 2000 operating systems, see "DVD and Microsoft Operating Systems," listed in "Storage References."

STOR–0360. DVD device provides 2 MB per second minimum transfer rate or better performance anywhere on the disc

The minimum sustained DVD device media transfer rate must be at least 2 MB per second for read operations from the DVD disc.

This requirement sets the minimum speed needed for DVD-Video playback during MPEG-2 decoding on Windows platforms. This requirement applies to the minimum read speed (2 MB per second) on any production level DVD-Video media, at any location on the disc. This minimum rate requirement does not apply to DVD data discs that the user records, or discs being read in error-correcting, defect management mode. OEMs must continue to ship DVD drives that produce an acceptable user experience and conform to the specifications cited in
STOR–0341, "Storage components and optical devices support bus master capabilities," and STOR–0353, "CD or DVD drive supports specified logical and physical CD formats."

STOR–0361. DVD drive supports defect management

DVD drives must support defect management that is transparent to the operating system, according to industry standards. Defect management for DVD-RAM media is defined in DVD Specifications for Rewritable Disc, Part 1: Physical Specifications, published by Toshiba Corporation. Defect management for DVD+RW is defined in ECMA-274. Information on ECMA-274 is listed in "Storage References."


CD Devices

This section describes the requirements for CD devices.

STOR–0362. CD device provides 8x minimum transfer rate or better performance

This requirement sets the minimum speed (1200 KB per second when running in the fully on power state) needed for production-level CD reading on Windows platforms. This requirement applies to the minimum read speed (8x) on any production-level CD media, such as application or game software, at any location on the disc. This minimum speed requirement does not apply to end-user recorded CD data discs or discs being read in error-correcting, defect management mode, or to CD devices attached on buses such as USB 1.0 or later that cannot sustain this data rate.


Rewritable Optical ATAPI Devices

This section summarizes specific requirements for rewriteable optical storage devices. The device must also meet the general requirements defined in "PC 2001 Design for Storage Components."

STOR–0363. Block rewriteable optical ATAPI device complies with INF-8070i, version 1.2

INF-8070i defines the requirements for block rewriteable ATAPI devices, including specifications for logical unit number (LUN) implementation, media status notification, and device write protection. This document also includes required support for the Read Format Capacities command.


PC 2001 Design for Storage Components

This section summarizes requirements related to Plug and Play and other resource-related design issues for storage devices.

STOR–0364. Device and controller comply with Storage Device Class Power Management Reference Specification

The Storage Device Class Power Management Reference Specification, Version 1.0 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 possible wakeup event definitions for the class. Support is required for power states D0, D1, and D3 for hard disks, CD and DVD drives, and other mass storage devices. Hard disks, CD, and DVD drives, and other mass storage devices are required to resume properly from the D3 power state after power to the device is removed. Support for the D1 state is not required for floppy disk devices.

If implemented, the ability to cause a wakeup event must meet the requirements as defined in the Storage Device Class Power Management Reference Specification, Version 1.0.


Device Drivers and Installation for Storage

This section summarizes the basic requirements for device drivers and installation procedures for storage devices.

STOR–0365. Device driver for partitioned media supports all Windows Me and Windows 2000 partition types

Device drivers that support partitioned media must support all Windows Me and Windows 2000 partition types, which include but are not limited to FAT 16, FAT 32, and Windows NT file system (NTFS).


Storage References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

AT Attachment with Packet Interface –5 (ATA/ATAPI-5)

ftp://fission.dt.wdc.com/pub/standards/x3t13/project/d1321r3.pdf

ATA and ATAPI draft standards and other working documents

http://www.t13.org

ATAPI Removal Rewriteable Media Devices (INF-8070i)

ftp://fission.dt.wdc.com/pub/standards/SFF/specs/INF-8070.PDF
Other ATA and SCSI standards
Global Engineering Documents
http://global.ihs.com/

"DVD and Microsoft Operating Systems"

http://www.microsoft.com/hwdev/devdes/dvdwp.htm

DVD Specifications for Rewritable Disc, Part 1: Physical Specifications

Published by Toshiba Corporation
http://www.toshiba.com

ECMA Standards: ECMA-267 (DVD-ROM), ECMA-272, 273 (DVD-RAM) and ECMA-274 (+RW)

http://www.ecma.ch/

Media Status Notification Support Specification, Version 1.03

http://www.microsoft.com/hwdev/respec/storspec.htm

MMC-2: See SCSI Multimedia Commands – 2.

MultiRead Specifications for CD-ROM, CD-R, CD-R/RW, & DVD-ROM Devices, Revision 1.11

http://www.osta.org/html/mrspec.html

Multisession Compact Disc Specification
CD EXTRA (Enhanced Music CD) Specification, Version 1.0

Philips Consumer Electronics B.V.
Coordination Office Optical–Magnetic Media Systems
Building SWA-109, PO Box 80002
5600 JB Eindhoven, The Netherlands
Fax: (31) (40) 732113

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/data/tech/ideboth.zip

Reduced Block Commands (RBC)

ftp://ftp.t10.org/t10/drafts/rbc/rbc-r10a.pdf

SCSI-3 Block Commands (SBC)

ftp://ftp.t10.org/t10/drafts/sbc/sbc-r08c.pdf

For more information on SBC standards, see
Global Engineering Documents
Phone: (800) 854-7179 (US)
(613) 237-4250 (Canada)
(303) 792-2181 (Outside North America)
Fax: (303) 397-2740
http://global.ihs.com/

SCSI-3 Parallel Interface (SPI)

ANSI X3.253-1995
http://web.ansi.org/public/std_info.html

SCSI Multimedia Commands – 2 (MMC-2)
ANSI NCITS 333-2000

ftp://ftp.t10.org/t10/drafts/mmc2/mmc2r11a.pdf

SCSI Parallel Interface – 2 (SPI-2)
ANSI X3.302-1998

http://web.ansi.org/public/std_info.html

SCSI Parallel Interface-3 (SPI-3)

ftp://ftp.t10.org/t10/drafts/spi3/spi3r14.pdf

Serial Bus Protocol 2 (SBP-2)
ANSI NCITS 325-1998

http://web.ansi.org/public/std_info.html

SPI, SPI-2: See SCSI-3 Parallel Interface (SPI).

Storage Device Class Power Management Reference Specification, Version 1.0

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

Storage Technology Web page

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

Universal Serial Bus Mass Storage Class Specification Overview, V1.0 Revision

http://www.usb.org/developers/devclass.html

Windows 98 DDK and Windows 2000 DDK

http://www.microsoft.com/ddk/


Checklist for Storage

STOR–0341. Storage components and optical devices support bus master capabilities

STOR–0342. Removable media devices support media status notification

STOR–0343. USB storage devices comply with the USB mass storage class specification

SCSI–0109. Differential devices support DIFFSENS as defined in SPI-3 or later standard

STOR–0345. External devices use automatic termination or an accessible termination switch

STOR–0346. Devices supports the STOP/START UNIT command as defined in the SBC standard

STOR–0347. Peripherals comply with ATA/ATAPI-5

STOR–0348. ATAPI devices support DEVICE RESET command

STOR–0349. ATA device supports ATA STANDBY command

STOR–0350. ATA devices support Ultra DMA

STOR–0352. CD or DVD drive is CD-Enhanced compatible

STOR–0353. CD or DVD drive supports specified logical and physical CD formats

STOR–0354. CD or DVD drive complies with MMC-2

STOR–0355. CD drive supports multisession and compatibility forms of the READ_TOC command

STOR–0356. CD or DVD changer complies with MMC-2

STOR–0357. CD or DVD device supports digital audio extraction with sector accurate reads

STOR–0360. DVD device provides 2 MB per second minimum transfer rate or better performance anywhere on the disc

STOR–0361. DVD drive supports defect management

STOR–0362. CD device provides 8x minimum transfer rate or better performance

STOR–0363. Block rewriteable optical ATAPI device complies with INF-8070i, version 1.2

STOR–0364. Device and controller comply with Storage Device Class Power Management Reference Specification

STOR–0365. Device driver for partitioned media supports all Windows Me and Windows 2000 partition types


Chapter 13 Modems

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter discusses modems that connect directly or indirectly to the Public Switched Telephone Network (PSTN). These include:

  • Voiceband modems used for data, fax, voice, text telephony, or video telephony.
  • ISDN modems.
  • Cellular and wireless modems, such as global system for mobile communications (GSM).

Unless this chapter defines a specific requirement or exception, all requirements for modems apply as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Voiceband Modems

This section describes the basic features required for all voiceband modems.

MOD–0366. Modem driver supports Unimodem

The device driver must include universal modem driver (Unimodem) support. Typically, this requires a modem INF file, developed and verified using the Modem Developers Kit (MDK) and pretested by the modem manufacturer.

MOD–0367. Modem meets PC 2001 controller requirements

The modem controller must support the following:

  • AT command buffer of at least 60 characters
  • Semicolon (;) character dial string modifier, except when the modem is configured for operation in those countries that prohibit this dial modifier
  • Unimodem Diagnostics command, AT#UD

The modem controller must also be capable of software-based feature upgrades, such as providing upgradeable ROM or a driver-based modem that meets the requirements in "Driver-based Modems" later in this chapter.

MOD–0368. Modem supports V.250 AT command set

International Telecommunication Union (ITU) Recommendation V.250 is a superset of the TIA-602 basic AT command set with significant and useful improvements. The following V.250 commands must be supported:

  • All basic mode commands from TIA-602 (no + prefix)
  • Identification: +GMI, +GMM, +GMR, +GCI
  • Port control: +IPR, +ICF, +IFC, +ILRR, +ITF (defined in V.80)
  • Modulation: +MS, +MR, +MA
  • Error control: +ES, +ER, +EB, +ESR, +ETBM
  • Compression: +DS, +DR

If the AT command for a particular function is implemented, the corresponding V.250 AT command must be supported.

The modem must also be able to generate appropriate V.250 responses enabled by the +ILRR, +MR, +ER, and +DR commands.

MOD–0369. Data modem meets PC 2001 protocol requirements

A PC 2001 modem must support the following protocols:

  • V.90 modulation
  • V.42 Link Access Protocol Modem error control
  • V.42 bis data compression
  • V.80 synchronous data access protocol
MOD–0370. Modem supports call control signaling, controlled using V.251 modem commands

Modems must support the ITU V.251 standard for PC-controlled call control, including:

  • DCE-controlled V.8 operation with DTE notification.
  • DTE-controlled V.8 operation (<a8a> values of 2, 3, and 4).
  • DTE-controlled V.8 bis operation.
  • Backward compatibility for media detection with terminals using V.25 signaling, for example, data calling tone and fax calling tone.
  • Backward compatibility for media detection with older modems, for example, V.32 and V.32 bis.
  • Modems must provide a means for turning on the V.8 Calling Indicator signal for originating calls. Modems must also meet requirements stated in the Videophone-ready Modem Handbook, Version 1.0, which describes the specific implementation details essential to support H.324 voice-band video conferencing.
MOD–0371. FAX modem supports 14.4 Kbps (V.17) with Class 1 command set

If fax modem capabilities are implemented, the fax modem must support 14.4 kilobits per second (Kbps) (V.17) with the Class 1 (ITU T.31) command set.

If fax modems include dax/data media detection (for example, T.32 +FAA command), the INF file must include the necessary registry keys, as defined in the MDK, which is provided in the Windows DDK.

MOD–0372. If delayed and blacklisted number tables are implemented, modem generates appropriate error messages

During certain international Post, Telephone, and Telegraph certification processes, modems must support the delayed and blacklisted numbers feature. For details, see European Telecommunications Standards Institute (ETSI) ETS 300 001.

For Windows compatibility, modems that support delayed and blacklisted number tables must:

  • Generate end-user legible error messages to report these conditions.
  • Provide modem INF file drivers that translate these error messages for Unimodem and Telephony Application Program Interface (TAPI).
MOD–0373. If TDD support is implemented, modem complies with TDD, meeting V.18-1996 with V.250 AT commands

People who are deaf or hard-of-hearing, and people who are unable to speak or who use synthetic speech, can communicate over phone lines using a TDD, also known as a Text Telephone.

ITU Recommendation V.18 codifies how all these devices work and how to adaptively connect to all of them. ITU Recommendation V.250 contains these AT commands for control of V.18 features in a modem: +MV18S, +MV18R, +MV18AM, +MV18P. Modems that support text telephony must support those parts of V.18 applicable to their target countries, and the V.18 commands listed earlier.

MOD–0374. If voice modem is implemented, it supports ITU V.253 (AT+V)

Voice modem features that are implemented must use the corresponding commands and responses defined in V.253.

MOD–0375. If implemented, V.253 modem supports duplex audio (+VTR)

The required formats for duplex audio are for 8-bit 8 kHz: unsigned linear and G.711.

MOD–0376. If Caller ID detection is implemented, modem supports Caller ID Reporting using +VCID and +VRID commands

If Caller ID detection is implemented, reporting must be controlled with the AT+VCID command from V.253. If Caller ID message reporting is implemented, it must be controlled with the AT+VRID command from V.253.

MOD–0377. Modem can connect, stay connected, and successfully transfer data simultaneously

This requirement states a basic criterion for modem functionality. While operating in the default modem configuration on TIA-3800 line I01d-loop 3, the modems must be able to transfer a typical file in 40 minutes or less, simultaneously in both directions, without hanging up or otherwise aborting the transfer. Data transmission is required to be run directly on the modems without the use of an additional protocol such as Zmodem.

The analog V.90 modem subject to this requirement must meet it when connected to digital V.90 modems commonly deployed by Internet service providers (ISPs). For modems certified for operation only in countries outside of North America, the requirement is for operation on impairment combination 2C4, as specified in International Telecommunication Union – Telecommunication Standardization Sector (ITU-T) Recommendation V.56 bis. V.56 bis. specifies that the modem must be connected to an identical analog modem, rather than a digital V.90 modem.

TIA TSB-38 provides detailed test procedures and criteria.

MOD–0378. Modem reliably connects numerous times on good telephone channels

This requirement cites basic modem functionality. While operating in the default configuration, the modem must be able to repeatedly connect, with an overall call completion success ratio of 97 percent and without the modem stalling in an unresponsive, inoperable state. This requirement must be met while operating on channels I01d from TIA-3800.

The analog V.90 modem must meet this requirement when connected to digital V.90 modems commonly deployed by ISPs.

TIA TSB-38 provides detailed test procedures and criteria for modems certified for operation in North America. ITU-T Recommendation V.56 ter provides detailed test procedures for modems only certified for operation outside of North America.

MOD–0379. Modem pair functions concurrently with other applications

For this requirement, the modem must be able to sustain a connection for at least 30 minutes, at no less than 90 percent of the initial connection rate and with no more than 2 retrains, while typical communications applications are running over the modem link on the PC, including:

  • E-mail: Outlook Express over Hotmail.
  • Web browsing: Internet Explorer.
  • Video teleconferencing: Netmeeting.

To meet this requirement, the analog V.90 modem must sustain connectivity when connected to digital V.90 modems commonly deployed by ISPs, using the same channel as described in MOD–0378, "Modem reliably connects numerous times on good telephone channels."

MOD–0380. All external USB modems support USB specifications

An external modem must comply with all related USB specifications, including:

  • Universal Serial Bus Specification, Revision 1.1.
  • Universal Serial Bus Class Definitions for Communication Devices, Version 1.0

External modems may also support V.24 (RS-232) serial interfaces for legacy connectivity.

For compatibility with Unimodem and Windows USB serial drivers, a USB modem that incorporates the modem controller function must support the mandatory and optional requests and notifications for Abstract Control Model Serial Emulation defined in section 3.5.1.2.1 of the Universal Serial Bus Class Definitions for Communication Devices, Version 1.0 specification.

Alternatively, external modems may support IEEE 1394 or Bluetooth instead of USB. If implemented as external Bluetooth modems, they must support one of the applicable profiles defined by the Bluetooth SIG specifications, such as Dial Up Networking (K:7), FAX profile (K:8), or LAN Access (K:9). For more information on Bluetooth specifications, see Specification of the Bluetooth System, Volume 1: Core, v1.0 B, and Volume 2: Profiles, v1.0 B, listed in "Modems References."

MOD–0381. Modem complies with device class power management reference specification

The Communications Device Class Power Management Reference Specification, Version 1.0, provides definitions for the OnNow device power states (D0–D3) for modems. The specification also covers the device functionality expected in each power state and the possible wakeup event definitions for the class.

Power states D0 and D3 are required for modems on power-managed buses, including PCI, CardBus, and USB. Modem adapters that use the PCI bus must be capable of generating a power management event (PME# assertion) from the D3cold device state.

MOD–0382. Modem supports wakeup events

A modem must be able to cause a wakeup event on an incoming ring as defined in the Communications Device Class Power Management Reference Specification. This requirement applies for modems on all power-managed buses, including PCI, CardBus, and USB.

The D2 power state is defined specifically for this purpose in the power management reference specification. The ability for a modem to cause a wakeup event from the D3 power state is also possible (D3 realizes better system power savings). To comply with this requirement, a modem must be able to cause a wakeup event from the D2 state, the D3 state, or both states.

PCI modem devices are required to support wake from D3cold on a system with auxiliary power. On all other power-managed buses (such as USB), support for either D2 or D3 is acceptable.


Driver-based Modems

This section covers requirements for controllerless or "soft" modems, whereby the modem controller function, or both the modem controller and the modem datapump functions, are implemented on the Windows host.

MOD–0383. Driver-based modem uses a WDM-based driver solution

Windows Me and Windows 2000 use the same WDM kernel calls. Driver-based modems must use the WDM kernel so that both operating systems can use a common driver binary. For Windows 2000, these drivers must also support symmetric multiprocessors.


ISDN Modems

This section covers requirements for serial-port connected ISDN terminal adapters, commonly referred to as "ISDN modems." See also "ISDN Requirements" in Chapter 14.

MOD–0384. ISDN modem supports required command set

An ISDN modem must support the following:

  • Basic AT commands such as TIA-602, which is a subset of ITU V.250
  • Commands to select the end-to-end protocol used over the ISDN, for example, synchronous point-to-point protocol (PPP), V.110, V.120, and so on
  • Commands to set the switch type, subscriber numbers, or directory numbers
  • Service profile ID (SPID) or EndgerateAushlZiffer (EAZ) (where applicable) for user selection or if auto-detection fails, implemented in the device or in the communications driver
MOD–0385. ISDN modem supports asynchronous-to-synchronous conversion and RFC 1662

Because ISDN is a synchronous service and an ISDN modem connects
to a logic asynchronous USB port on the PC, the device must provide
some means of converting asynchronous data to synchronous data. The asynchronous-to-synchronous conversion must support the requirements identified in RFC 1662.


Mobile Modems

This section covers the particular requirements of modems used in mobile systems. These are in addition to the requirements in the "Voiceband Modems" section earlier in this chapter.

MOD–0386. If wireless support is implemented, Mobile PC modem supports +WS46 command

Wireless modems and look-alike modems include the common types, such as North American analog cellular, cellular digital packet data (CDPD), GSM, and other digital cellular systems, as well as several other types.

All wireless and cellular modems must use the +WS46 command, which selects the WAN.

The TIA-678 +WS46 command has codes to indicate the system in which the modem can operate. For example, the following values, quoted from Table 4 of the standard, are useful.

Value | System
1 | Public telephone network (that is, a normal wireline modem)
4 | CDPD
7 | TIA-553 analog cellular system
10 | Metricom Ricochet network
12 | GSM digital cellular system
13 | TIA IS-95 CDMA digital cellular
14 | TIA IS-136 TDMA digital cellular (Personal Communications System)

Windows has registry keys that support analog cellular modems. Windows also supports data access in GSM and other wireless modem types.

MOD–0387. If digital cellular control is implemented, Mobile PC modem supports appropriate +C digital cellular standards

If digital cellular support is implemented, the following appropriate digital cellular control standards must be supported.

Standard | System and services
GSM 7.07 | GSM system: data, fax, voice
GSM 7.05 | GSM SMS
TIA IS-707 | North American CDMA: data and fax
TIA IS-135 | North American TDMA: data and fax

The following commands are required:

  • +CBC battery power monitoring command
  • +CPAS phone activity status
  • +CSQ signal quality-monitoring command
  • +CBST protocol selection command for GSM modems
  • Class 2.0 facsimile services, per appropriate standard

Digital cellular communications equipment must default to using error correction on the radio link. For example, for GSM 7.07, the modem must initialize to +CBST=,,1 (which selects a "nontransparent" air interface).

To allow data cards to use GSM/ISDN V.110 "fast access" where available in the network, +CBST=71,, ( 9600 bits per second (bps) V.110) must be a valid setting.

MOD–0388. If SMS support is implemented, the modem supports appropriate +C SMS control commands

To allow software applications to specify settings and manipulate short messaging services (SMS) through a GSM modem card, the card must support the following GSM 07.05 commands:

+CMGF: Message Format

+CMGL: List Messages

+CMGR: Read Messages

+CMGS: Send Messages

+CMGW: Write Messages

+CNMI: New Message Indications
to terminal equipment (TE)

+CPMS: Preferred Message Storage

+CRES: Restore Settings

+CSAS: Save Settings

+CSCA: Service Center Address

+CSCS: TE character set selection

+CSMS: Select Messaging Service

Unlike wireline data modems, these devices are not required to support V.34 signaling because none is available. Only 9600 bps capability is required.


Telephony

The increasing confluence of voice and data networks is driving the increased use of the PC as a communications device. PC systems that are compatible with acoustic requirements of the telephony network support easy and efficient two-way interactive voice communications, such as telephony, allowing users to use their existing PC audio devices for communication.

MOD–0389. System with telephony applications uses a common set of audio I/O devices for system audio and telephony applications

If the system enables telephony applications such as speakerphone, IP telephone, and so on, then for each type of audio I/O device, the same device must be usable for both system audio and telephony. For example, the same set of speakers must be usable for both system audio and speakerphone functions. When using a headset, users must not need to change plug locations when switching from, for example, listening to CD-audio to speaking on the phone.

This requirement ensures that one convenient, unambiguous I/O connector is provided for each type of audio I/O device. It does not mandate that all audio I/O is delivered to a single I/O device at all times. For example, providing system audio sounds to the speakers while simultaneously using a headset for IP telephony would not be prohibited.

MOD–0390. Telephony applications provided with a PC 2001 system meet industry telephony performance requirements

If the system enables telephony applications that support devices, such as speakerphone or handset telephony, using various types of connections, such as plain old telephone service (for example, through a voice modem) or IP (through a network connection), the applications provided with the system must comply with telecommunications industry requirements for such parameters as send and receive loudness, echo, and so forth.

Speakerphone applications must meet the requirements in ITU-T Recommendation P.340, Transmission characteristics of hands-free telephones. Other applications must meet the requirements in ITU-T Recommendation P.310, Transmission characteristics for telephone band (300-3400 Hz) digital telephones. For additional information for IP telephony functions, see U.S. Committee T1 Technical Report No. 56, Performance guidelines for voiceband services over hybrid internet/PSTN connections, which provides useful guidance for IP telephony functions.


Modems References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Communications Device Class Power Management Reference Specification, Version 1.0

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

European Telecommunications Standards Institute (ETSI) or Global System for Mobile (GSM) standards

E-mail: publications@etsi.fr
http://www.etsi.org

ITU communications standards

ITU Sales
E-mail: sales@itu.int
http://www.itu.int

Plug and Play specifications

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

RFC 1662

http://www.rfc-editor.org/rfc.html

Specification of the Bluetooth System, Volume 1: Core, v1.0 B
Specification of the Bluetooth System, Volume 2: Profiles, v1.0 B

Bluetooth Special Interest Group (SIG)
http://www.bluetooth.com

TIA and other standards

Global Engineering Documents
E-mail: global@ihs.com
http://global.ihs.com

Unimodem Diagnostics Command Reference Specification

http://www.microsoft.com/hwdev/respec/commspec.htm

Universal Serial Bus Class Definitions for Communication Devices, Version 1.0

http://www.usb.org/developers/devclass_docs.html

Universal Serial Bus Specification, Revision 1.1

http://www.usb.org/developers/docs.html

Videophone-ready Modem Handbook, Version 1.0

http://developer.intel.com/ial/vidred/index.htm

Windows 98 DDK and Windows 2000 DDK, including information about WDM and Windows MDK

http://www.microsoft.com/ddk/


Checklist for Modems

MOD–0366. Modem driver supports Unimodem

MOD–0367. Modem meets PC 2001 controller requirements

MOD–0368. Modem supports V.250 AT command set

MOD–0369. Data modem meets PC 2001 protocol requirements

MOD–0370. Modem supports call control signaling, controlled using V.251 modem commands

MOD–0371. FAX modem supports 14.4 Kbps (V.17) with Class 1 command set

MOD–0372. If delayed and blacklisted number tables are implemented, modem generates appropriate error messages

MOD–0373. If TDD support is implemented, modem complies with TDD, meeting V.18-1996 with V.250 AT commands

MOD–0374. If voice modem is implemented, it supports ITU V.253 (AT+V)

MOD–0375. If implemented, V.253 modem supports duplex audio (+VTR)

MOD–0376. If Caller ID detection is implemented, modem supports Caller ID Reporting using +VCID and +VRID commands

MOD–0377. Modem can connect, stay connected, and successfully transfer data simultaneously

MOD–0378. Modem reliably connects numerous times on good telephone channels

MOD–0379. Modem pair functions concurrently with other applications

MOD–0380. All external USB modems support USB specifications

MOD–0381. Modem complies with device class power management reference specification

MOD–0382. Modem supports wakeup events

MOD–0383. Driver-based modem uses a WDM-based driver solution

MOD–0384. ISDN modem supports required command set

MOD–0385. ISDN modem supports asynchronous-to-synchronous conversion and RFC 1662

MOD–0386. If wireless support is implemented, Mobile PC modem supports +WS46 command

MOD–0387. If digital cellular control is implemented, Mobile PC modem supports appropriate +C digital cellular standards

MOD–0388. If SMS support is implemented, the modem supports appropriate +C SMS control commands

MOD–0389. System with telephony applications uses a common set of audio I/O devices for system audio and telephony applications

MOD–0390. Telephony applications provided with a PC 2001 system meet industry telephony performance requirements


Chapter 14 Network Communications

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter presents requirements for network adapters and related networking technologies.

Network communications requirements are based on Network Driver Interface Specification 5.0 (NDIS 5.0). The Windows 2000 DDK defines the networking requirements, services, terminology, and architecture for the Windows family of operating systems.

Windows uses Bluetooth Wireless Technology as a wireless peripheral bus for cable replacement. NDIS miniport drivers are not required for Bluetooth devices. Requirements for Bluetooth HCI devices and peripherals are listed in Chapter 6, "Buses and Interfaces."

Note: In this chapter, references to adapters, network interfaces, and so on, apply to add-on network adapter cards, network implementations on the system board, and external network interfaces equally and without preference for any of these types of implementation, unless otherwise noted.

Unless this chapter defines a specific requirement or exception, all requirements apply for networking solutions as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Network Adapter Requirements

This section defines basic hardware feature requirements for all network adapters, including IEEE 802 LAN adapters, ISDN adapters, cable modems, ATM adapters, ADSL, and so on. The applicable requirements for each device category are listed in the related sections later in this chapter.

NET–0245. Network adapter uses NDIS 5.0 miniport driver

The network adapter driver must be based on and comply with NDIS 5.0 in order to take advantage of new operating system capabilities. The driver must follow the NDIS 5.0 miniport driver model defined in the Windows 2000 DDK.

Important: The development of full media access control (MAC) drivers is no longer supported.

If the network device is for connection-oriented media, such as ATM, ISDN, frame relay, or X.25, it must have a connection-oriented miniport driver that follows the connection-oriented model defined for NDIS 5.0. Also, for connection-oriented media, there must be an NDIS 5.0 call manager driver as defined in the Windows 2000 DDK.

In some cases, such as ATM, the call manager driver is included in the operating system. Consequently, for an ATM adapter, the vendor needs to provide only an NDIS 5.0 connection-oriented miniport driver. For connection-oriented media such as ISDN or X.25, the vendor must provide a call manager driver with the hardware, because the call manager is not included in the operating system. Call manager support can be integrated in the connection-oriented miniport driver or implemented as a separate NDIS 5.0 call manager driver. Documentation for both integrated and separated call managers is included in the Windows 2000 DDK.

An NDIS 5.0 miniport driver is required for network adapters that connect to the PC using IEEE 1394 or USB buses. This driver exposes its media type to NDIS 5.0 at its upper edge, and it interfaces with the appropriate bus driver at its lower edge.

NET–0246. Adapter automatically senses presence of functional network connection

Where the network allows it, the network adapter must be capable of dynamically determining whether it is functionally connected to a link partner such as a hub, switch, or router. The device must indicate the link state in the following cases:

  • At boot time
  • After returning to D0 power state
  • When the link state changes while in the D0 power state (no time limit is specified for the required detection or status indication)

If the adapter is on an expansion card that is not used as a boot device, the device drivers can determine the presence of the functional link. If the adapter is not functionally connected to a link partner, the miniport driver must provide appropriate NDIS status indication using support for cable sense in NDIS 5.0.

For information about NDIS status codes and indication mechanisms, see the Windows 2000 DDK.

NET–0247. Adapter automatically senses transceiver type

Network adapters that support multiple transceivers must be capable of automatically detecting which transceiver type is connected to the network unless detection is not possible with the network media available. The network adapter then must automatically drive the correct connection. 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.

NET–0248. Adapter can transmit packets from buffers aligned on any boundary

Buffer alignment refers to whether a buffer begins on an odd-byte, word, double word, or other boundary. Adapters must be able to transmit packets, any of whose fragments are on an odd-byte boundary.

For performance reasons, packets must be received into contiguous buffers on a double word boundary.

NET–0249. Adapter communicates with driver across any bridge

If the adapter uses a bridge, all communications must be free of errors across any bridge, such as a PCI bridge adapter.

NET–0250. Networking media supports IP

Any networking media must support IP, yet not preclude the use of other protocols.

NET–0251. PCI-based network adapters are bus masters

The PCI-based network adapter must support PCI bus mastering. PCI bus mastering must be enabled by default. CardBus and mini-PCI implementations need not be bus masters.


Connectionless Requirements

This section lists the requirements related to connectionless media, such as IEEE 802 LAN adapters (with the exception of wireless) and Fiber Distributed Data Interface (FDDI) adapters.

NET–0252. NDIS 5.0 miniport driver is deserialized

NDIS 5.0 introduces support for deserialized miniports. This feature enables performance improvements and scalability on Windows 2000 multiprocessor systems.

NET–0253. Full-duplex adapter automatically detects and switches to full duplex mode

If both the network adapter and switch port in a link pair support full duplex and there exists a standard way for each to detect and negotiate the duplex mode, the network adapter must negotiate full-duplex mode operation by default. Half-duplex mode can be used if that is the only mode supported by one or both link partners, or it can be manually configured if warranted by special conditions. The goal is to configure this setting automatically without end-user intervention.

NET–0254. Adapter supports filtering for at least 16 multicast addresses

This requirement applies to networking technologies, such as Ethernet, that support multicast. This requirement does not apply to technologies such as Token Ring, which distributes IP multicast traffic using the functional address as specified in RFC 1469, listed in "Network Communications References."

NET–0255. Adapter and driver support promiscuous mode

Promiscuous mode ensures that the adapter can be used with Microsoft Network Monitor Agent. This requirement applies only to LAN (nonswitched) media.

Notice that, by default, promiscuous mode is not on. Enabling promiscuous mode must be possible only by using the Microsoft Network Monitor Agent or another similar administrative application.

NET–0256. Adapter can be used as a boot device

A PC system designed for use with Windows 2000 must include remote boot support as defined in the Preboot Execution Environment (PXE) Specification, Version 2.1. This support may either be included on the adapter, in the system BIOS, or the support may be split between the adapter and the BIOS. See
BIOS–0014.1, "BIOS supports PXE," in Chapter 3.

Note: This is not a requirement for Cardbus adapters or for mini-PCI adapters that are not sold as a part of or with a PC system.

NET–0257. Network adapter and driver supports priority for IEEE 802-style networks

Windows Quality of Service (QOS) components provide link layer priority information to NDIS 5.0 miniport drivers in each transmitted packet’s NDIS_PER_PACKET_INFO structure.

Priority values are derived by mapping Internet Engineering Task Force (IETF) Integrated Services (IntServ, RFC 1663) service typed to IEEE 802.1p priority values, referred to as the user priority object. Current IETF references include:

  • The Subnet Bandwidth Manager.
  • Framework for integrated services over 802 networks.
  • Mapping integrated services to 802.1p.

The IntServ service type used for the mapping is determined by QOS-aware applications or, on behalf of the application, by QOS-aware operating system components. Driver support for link layer priority information must adhere to IEEE 802.lp priority values.

IEEE 802.1p/q-capable Ethernet drivers must use the priority level indicated in the NDIS_PER_PACKET_INFO structure to generate the corresponding field in the IEEE 802.1p/q MAC headers of transmitted packets. Similarly, these drivers must extract the appropriate information from the MAC headers of received packets and copy the priority to the NDIS_PER_PACKET_INFO structure before indicating the packet to higher protocol layers.

Notice that any link layer driver has the ability to interpret the priority information in the NDIS_PER_PACKET_INFO structure and use it as appropriate for the particular media.

For more information, see the Windows 2000 DDK and "QOS: Assigning Priority in IEEE 802-style Networks."


ISDN Requirements

This section summarizes the design features for ISDN devices. It defines general requirements for ISDN and specific requirements for ISDN terminal adapters. For information about the requirements for ISDN modems, see Chapter 13, "Modems."

The phrase "ISDN modem" indicates an ISDN device that operates as a modem controlled by the AT command set.

In this section, "internal ISDN device" refers to the ISDN terminal adapter, which exposes raw access to its B channels using NDIS miniports. Alternatively, ISDN terminal adapters could be attached to the PC using WDM-supported bus classes such as USB or IEEE 1394, which would physically be an external device.

NET–0258. Internal ISDN device meets PC 2001 network adapter requirements

ISDN adapters must meet all requirements stated in "Network Adapter Requirements," with the exception of NET–0251, "PCI-based network adapters are bus masters." PCI ISDN adapters are not required to be bus masters.

NET–0259. Internal ISDN device supports synchronous HDLC framing

High-level Data Link Control (HDLC) framing is a standard for sending synchronous data. Other framing methods are allowed if the miniport driver provides simple HDLC-framed, synchronous PPP packets to NDIS.

NET–0260. NDIS interface and driver support raw, unframed synchronous B channel I/O

The internal ISDN device and the driver must support raw, unframed (non-HDLC) synchronous B channel I/O at 64 Kbps per B channel, with each B channel individually accessible. This support enables H.320 as well as voice calls over ISDN without audio breakup.

For these raw interfaces, the direct path to each B channel must support synchronous transmission and reception of H.221 frames, which are of 20 ms duration. Since underruns or overruns cause degraded audio, hardware buffering must be adequate to prevent B channel underruns and overruns. For Windows Me and Windows 2000, 20 ms is adequate.

NET–0261. ISDN driver supports unattended installation, with limitations

Configuration of the dependent parameters, such as SPIDs and switch-type IDs, must be done through the ISDN configuration wizard included in the operating system.

NET–0262. ISDN device includes software-selectable terminating resistors

If the ISDN device has an S/T-interface for connecting additional ISDN devices, it must also have software-configurable terminating resistors that can be selected on or off. The default value of the termination is on in North America, but off in all other countries, where phone companies unconditionally provide the termination.


Cable Modem Requirements

Cable modem provides two-way services: data flows downstream from the cable operator’s head end and upstream from the customer’s PC. At the head end, the cable data system is terminated by the cable modem termination system (CMTS), which terminates the upstream and downstream RF, MAC layer, and possibly Layer 3 protocols from the cable side. CMTS provides the internetwork connection between the cable system and the rest of the network at the head end. CMTS can be implemented on a proprietary hardware platform or a PC platform running Windows 2000. CMTS can provide different networking functions such as routing or QOS support, for example, Resource Reservation Setup Protocol (RSVP).

The three current cable modem specifications are:

  • Data-Over-Cable Service Interface Specifications (DOCSIS) developed by the Multimedia Cable Network System (MCNS) consortium.
  • IEEE 802.14 Cable TV Working Group, developed by IEEE.
  • Digital Video Broadcasting/Digital Audio-Visual Council (DVB/DAVIC), developed by DAVIC and DVB and adopted by European Telecommunications Standards Institute (ETSI) and ITU.

Industry support for DOCSIS is growing rapidly in North America. In present form, its upper layers fully describe IP traffic encapsulated by 802.3/Digital-Intel-Xerox (DIX) Ethernet framing. ATM is left for future study.

External Ethernet DOCSIS cable modems provide IEEE 802.1d bridging for one or more customer premises equipment. A PC attaches to the cable modem indirectly through its 10B-T network adapter. Integrated cable modems attach directly to the PC over buses such as USB, PCI, and IEEE 1394, and they require a vendor-supplied NDIS 5.0 miniport driver. This driver exposes an 802.3/DIX Ethernet adapter interface to the operating system.

In contrast to DOCSIS, both the IEEE 802.14 and the DVB/DAVIC efforts are focused on using ATM, typically implementing an ATM adapter interface and using an NDIS 5.0 ATM miniport driver.

NET–0263. Integrated cable modem meets PC 2001 network adapter requirements

Cable modems must meet all requirements stated in "Network Adapter Requirements." In addition, the requirement NET–0254, "Adapter supports filtering for at least 16 multicast addresses" applies for an integrated cable modem exposing an Ethernet interface.

NET–0264. Integrated cable modem exposes an ATM or Ethernet interface

An integrated cable modem must expose an ATM or Ethernet interface to the operating system. For the specific requirements if an ATM/cable modem solution is implemented, see "ATM Adapter Requirements."


ATM Adapter Requirements

This section summarizes requirements for ATM hardware. These requirements also apply to Asymmetric Digital Subscriber Line (ADSL) devices; see "ADSL Requirements."

The NDIS 5.0 extensions provide kernel-mode NDIS 5.0 client drivers with direct access to connection-oriented media such as ATM. The new architecture for Windows Me and Windows 2000 extends native ATM support to Windows Sockets 2.0 (WinSock), TAPI, and DirectShow-based applications by providing system-level components that map the applicable WinSock, TAPI, and DirectShow APIs to NDIS 5.0, extending direct ATM access to user-mode applications.

If ATM is included in a PC 2001 system or is specifically designed for Windows Me or Windows 2000, it must meet the requirements defined in this chapter.

For more information related to these requirements, see "ATM Layer Specification," in ATM User Network Interface (UNI) Specification Version 3.1, 1/e. This specification includes references to other relevant specifications.

NET–0265. ATM adapter meets PC 2001 network adapter requirements

ATM adapters must meet all requirements stated in "Network Adapter Requirements."

NET–0266. ATM adapter supports a minimum number of simultaneous connections

The virtual path ID (VPI) and virtual channel ID (VCI) ranges supported by the adapter affect the maximum number of simultaneous connections supported on a system.

This affects the applicability of the adapter to ATM applications such as LAN emulation, where at least one dedicated virtual channel (VC) is created between each pair of communicating ATM hosts.

System type | Simultaneous connections
Client (ATM adapter) | 64 or more
Client (Integrated ATM/ADSL adapter) | 32 or more

A sample driver is provided in the Windows 2000 DDK to guide developers in properly supporting resources to meet this requirement.

NET–0267. ATM adapter supports UBR service type

Unspecified bit rate (UBR) service is used by default for standard ATM services such as LAN Emulation and IP over ATM. In addition, PPP is a widely used model for residential network access, and UBR is used by default for PPP-over-ATM virtual circuits. Therefore, ATM adapters must support the UBR service type.

NET–0268. ATM adapter supports a minimum number of simultaneously active VBR or CBR connections

Support is required for at least two simultaneously active variable bit rate (VBR) or constant bit rate (CBR) connections for basic ATM signaling and management. Support for at least six VBR/CBR connections is needed for ATM adapters that support multimedia or other traffic that demands QOS.

NET–0269. ATM adapter supports traffic shaping

The ATM adapter must support and enforce all the traffic-shaping rules specified for each service type it supports, including CBR, VBR, available bit rate (ABR), and UBR. This includes enforcement of peak cell rate on UBR virtual circuits, as described in the following requirement.

NET–0270. ATM adapter enforces PCR on UBR virtual circuits

ATM adapters can be used to connect the router, remote access, and content servers to the public ATM network. High-speed residential broadband access networks, such as ADSL and cable modem, can enable direct connection, using an ATM virtual circuit, from home or small office computers to these servers.

To avoid packet loss and ensure efficient network utilization, it is critical that all ATM adapters, integrated ATM/ADSL adapters, and ATM/cable modem adapters enforce requested PCR on UBR virtual circuits. ATM adapters must be able to schedule cells on a UBR virtual circuit at a peak rate less than the line or link rate.

Because any ATM adapter might be installed in a server to which clients connect through the public network, this requirement applies to all ATM adapters.

NET–0271. ATM adapter and driver support dynamic link speed configuration

When connected to a residential broadband network, an ATM adapter must restrict the aggregate transmission rate across all active virtual circuits so that it does not exceed the upstream bandwidth provided by the residential broadband network.

Therefore, all integrated ATM/ADSL adapters and ATM/cable modem adapters must support aggregate shaping of upstream bandwidth, according to the provisioned upstream bandwidth or the trained bandwith, whichever is lower. Some implementations can support rate adoption, and lower-than-provisioned rates might be negotiated because of poor line conditions. In addition, because any 25 Mbps ATM adapter might be used to connect to an ADSL network by way of an external ADSL modem, it is required that all 25 Mbps ATM adapters support this as well. This support is optional for ATM adapters with line rates higher than 25 Mbps.

The Windows ATM Call Manager uses Interim Local Management Interface (ILMI) to query the public network to determine the maximum line rates provisioned for incoming and outgoing traffic. The Call Manager then uses the OID_GEN_CO_LINK_SPEED NDIS request (in SET mode) to set the line rate for both incoming and outgoing traffic, within which the adapter can shape the aggregate of all ATM traffic.

NET–0272. ATM adapter that supports OAM responds to F4 and F5 loopback cells

Adapters that receive F4 and F5 loopback operation and maintenance (OAM) calls must be responded to on adapters that support OAM. This capability is needed for diagnostics. Support for layers F1–F3 is optional.


ADSL Requirements

This section summarizes requirements for ADSL hardware.

Note: All ATM requirements also apply to ADSL devices.

Windows Me and Windows 2000 provides support for ADSL adapters and external ADSL modems, such as those using USB, which provide a faster method for moving data over regular phone lines.

Thirty leading ADSL vendors jointly developed the white paper, An Interoperable End-to-end Broadband Service Architecture over ADSL Systems (Version 3.0), which discusses end-to-end service interoperability over ATM over ADSL. The core idea of this white paper (PPP over ATM over ADSL) has been adopted by the ADSL Forum. This paper is available at the Web site listed in "Network Communications References."

NET–0273. Integrated ADSL modem meets PC 2001 network adapter requirements

ADSL modems must meet all requirements stated in "Network Adapter Requirements." In addition, integrated ADSL modems exposing an Ethernet interface must meet NET–0254, "Adapter supports filtering for at least 16 multicast addresses."

NET–0274. DSL modem supports G.994.1

ITU-T G.994.1, Handshake procedures for digital subscriber line (DSL) transceivers, is the international standard that defines mechanisms to allow DSL transceivers to exchange capabilities and to select a common mode of operation. G.994.1 supports modulation standards G.991.1 High bit-rate Digital Subscriber Line (HDSL), G.992.1 (full-rate discrete multitone [DMT] ADSL), G.992.2 ("G.lite" DMT ADSL), T1.413 Issue 2 (ANSI full-rate ADSL), and T1 TR-59 (CAP/QAM).

Use of G.994.1 allows the customer premises and central office DSL modems to negotiate a common mode of operation, and more importantly, identifies the cause of failure when the link is not established due to the incompatible modes of operation of the two modems.

NET–0275. CAP/QAM ADSL modem supports T1 TR-59

U.S. T1 committee Technical Report TR-59, "Single-Carrier Rate Adaptive Digital Subscriber Line (RADSL)," is the industry consensus specification for CAP/QAM ADSL modems. ADSL modems that support CAP/QAM modulation must implement TR-59. CAP/QAM ADSL modems may also support other modulation methods such as DMT.

Note: TR-59 is not a U.S. ANSI standard for ADSL modems, but is supported by some network access providers.

CAP/QAM ADSL modems must support G.994.1.

NET–0276. DMT ADSL modem supports G.992.2

ITU-T G.992.2, also known as G.lite, is the international standard for DMT modems, which includes features to facilitate easy, end-user installation. ADSL modems that support DMT modulation must implement G.992.2. DMT ADSL modems also may support other modulation standards, such as G.992.1, ANSI T1.413 Issue 2, or other modulation methods such as CAP/QAM, and so forth.

DMT ADSL modems must:

  • Support the L0 (Full On) and L3 (Idle) link states.
  • Support the T0e, T0f, T3a, and T3b link transitions.
  • Support G.994.1.


Wireless Networking

Wireless networking media types enable WAN, LAN, and personal area network (PAN) connectivity. This section lists additional requirements for wireless media. For wireless modem requirements, see Chapter 13, "Modems." For more information about Bluetooth devices, see "Bluetooth" in Chapter 6. In addition, wireless adapters must support filtering for at least 16 multicast addresses. See NET–0254, "Adapter supports filtering for at least 16 multicast addresses."

NET–0278. Wireless networking media adapters support wireless extensions to NDIS

Wireless extensions to NDIS are documented in "Network-Dependent Wireless Objects" in Network Drivers in the Windows 2000 DDK. These extensions are based on the work of the Portable Computer and Communications Association, published in STD-201: Extensions to NDIS for Wireless WANs, listed in "Network Communications References."

NET–0279. IEEE 802.11 wireless networking adapters support industry specifications

IEEE 802.11 wireless networking adapters must support 11Mbps signaling using Direct Sequence Spread Spectrum.


IrDA Requirements for Network Communications

The interface between IrDA hardware (framers) and the Windows IrDA stack is through NDIS 5.0 miniport drivers that adhere to the conventions defined in Infrared Extensions to the NDIS Version 4.0 Functional Specification. The Windows IrDA stack expects that hardware and NDIS drivers deal with framing, transparency, and error detection, as well as supporting media-sense and speed-change commands. Miniport drivers are responsible for discarding incoming frames with bad cyclic redundancy checks. Never forward these frames to the protocol.

Although the IrDA protocol stack in Windows 2000 is different from the one on Windows Me, use the Windows 2000 DDK for driver development for both platforms. The Windows 2000 IrDA protocol stack imposes stricter requirements on drivers than the protocol stack on Windows Me.

NET–0280. Infrared device meets PC 2001 network adapter requirements

IrDA devices must meet all requirements stated in "Network Adapter Requirements."

NET–0281. Infrared device supports both FIR and SIR

All infrared devices must comply with approved IrDA specifications, including support for SIR, FIR, and optional Very Fast IR (VFIR) data devices.

NET–0282. IrDA hardware supports unattended driver installation

FIR Plug and Play hardware must report a unique Plug and Play ID that matches the combination of the chip set, transceiver, and any other system-specific parameters for the operating system to find and install the correct INF file and the associated driver for the IrDA hardware.

In the best case, the IrDA hardware has only one Plug and Play ID associated INF file and a miniport driver that can autodetect the transceiver type and other system-specific parameters. This combination enables the installation and configuration of the hardware and the driver without user intervention.

In other cases, for example, where the miniport driver cannot autodetect the transceiver type or any other system-specific parameters, a unique Plug and Play ID for each combination of the chip set and the transceiver type must be reported. Also, the vendor must provide for each combination an associated driver and INF file describing the configuration parameters.


Home Networking Media

New networking media types are being invented to make it easy for PC users in homes and small businesses to implement simple LANs without needing to install new wires. This section lists additional requirements for these media. The media types listed in this section cover wireless and re-use of existing telephone wiring.

NET–0283. If implemented, home networking adapter meets PC 2001 network adapter requirements

Home network adapters must meet all requirements stated in "Network Adapter Requirements." In addition, they must meet following requirements:

  • NET–0254, "Adapter supports filtering for at least 16 multicast addresses"
  • NET–0255, "Adapter and driver support promiscuous mode" for network media that confine network traffic signals within a single home
NET–0284. Network adapter that supports Home RF complies with SWAP specification

A PC 2001 network adapter that implements HomeRF, must comply with Shared Wireless Access Protocol (SWAP) Specification, Version 1.1. The HomeRF Working Group (HRFWG) publishes this specification, which is listed in "Network Communications References." The Web site has a technical summary and document ordering information.

NET–0285. If implemented, network adapter that supports HomePNA complies with 1.0 specification.

A PC 2001 network adapter that implements HomePNA technology must comply with the Home Phoneline Networking Alliance Spec, Version 1.0.


Plug and Play and Bus Design for Network Communications

The items in this section are requirements for Plug and Play capabilities.

NET–0286. Plug and Play capabilities support multiple adapters

For network communications devices, the Plug and Play IDs and resource support must be sufficient to allow the automatic addition of multiple network communications devices to the system.

NET–0287. All resource settings are reported in the user interface

All resource settings must be viewable in the Device Manager and in the adapter properties dialog boxes. All resource settings that can be changed by the user must be changed using the standard Windows user interface, not through the use of INI files or other setting files.

This requirement implies that all device resources must be set and read through the standard interfaces provided by the bus on which the device resides. For PCI devices, this interface is the PCI configuration space. Also, device parameter settings must be stored in the registry.

NET–0288. External networking devices support standard control interfaces

External networking devices attached using a serial bus (USB, USB 2.0, IEEE 1394, or Bluetooth) must support standard control interface specifications where applicable.

All external USB networking devices must support Universal Serial Bus Class Definitions for Communication Devices, Version 1.1 (CDC 1.1), listed in "Network Communications References."

If implemented, external USB networking adapters must support one of the following:

  • Ethernet connection model (CDC 1.1)
  • Remote NDIS over CDC 1.1
  • COMMON ISDN-API (CAPI) over CDC 1.1 (ISDN adapters)

If implemented, external IEEE 1394 networking adapters must support remote NDIS over SBP-2.

If implemented, external Bluetooth network devices must support at least one of the applicable profiles defined by the Bluetooth SIG, such as Specification of the Bluetooth System, Volume 2: Profiles, v1.0B.


Power Management for Network Communications

This section summarizes the specific power management requirements for network communications devices.

NET–0289. Adapter complies with network power management specification

The Network Device Class Power Management Reference Specification, Version 1.0a, provides definitions of the OnNow device power states (D0–D3) for network adapters. The specification also covers the device functionality expected in each power state and the possible wakeup event definitions for the class.

Network communications devices that directly attach to the PC over USB, PCI, and IEEE 1394 must comply with this specification.

NET–0290. Network device supports wakeup events

This requirement applies specifically to the following network communications devices and their associated NDIS 5.0 miniport drivers:

  • Ethernet and Token Ring network adapters
  • Integrated DOCSIS cable modems
  • Other devices that transfer IEEE 802.3/DIX Ethernet framed packets

Note: Network Device Class Power Management Reference Specification, Version 1.0a, does not yet define wakeup mechanisms for ISDN adapters or any network communications adapter that uses ATM signaling, including ADSL.

The system must be capable of wakeup from a lower power state based on network events that are specified by the local networking software. As a result of this capability, any standard Windows network access—such as connections to shared drives and WinSock connections, plus service and management applications—can wake a system from lower power states transparently.

External networking devices using USB or IEEE 1394 are not required to support Wake on LAN while operating on bus power. No wireless network connection is required to support Wake on LAN.

Mobile PC Note

For mobile PCs, network device wakeup is not required.

As defined in Network Device Class Power Management Reference Specification, a network adapter and its driver must support wakeup on receipt of a network wakeup frame. Support for wakeup on detection of a change in the network link state or on receipt of a magic packet event is optional. Implementation details are described in the "Network Wakeup Frames" and "Network Wakeup Frame Details" sections of Network Device Class Power Management Reference Specification, Version 1.0a, and in the Windows 2000 DDK.

The packet patterns that define the wakeup frames are provided to the NDIS 5.0 miniport driver by the operating system. To enable Wake on LAN capability for basic networking scenarios, the network adapter must be capable of storing information describing a minimum of three wakeup packet patterns and of generating a wakeup indication on recognition of any wakeup packet. A wakeup packet is a packet that includes a wakeup pattern anywhere within the first 120 bytes of the packet. The minimum set of wake-up packets that must be recognized are the following:

  • A packet directed to at least one IP address
  • An IP address resolution protocol (ARP) packet
  • A packet containing NetBIOS name queries, or any arbitrary string

PCI-based network adapters must support the generation of a power management event (PME# assertion) from the D3cold device state if the physical layer technology is generally capable of operating under the voltage and current constraints of the D3cold device state.

Note: 1000baseSX or 1000baseLX (gigabit Ethernet using optical fiber media) cannot meet this requirement because of the power required to operate the optical physical layer. The same applies for FDDI adapters.


Device Drivers and Installation for Network Communications

This section summarizes requirements for network communications device drivers, in addition to the requirements for using an NDIS 5.0 miniport driver.

NET–0291. Driver works correctly with Microsoft network clients and protocols

This requirement includes the 32-bit Microsoft client and NetWare-compatible clients provided with Windows, whether connected to a Windows 2000 server, a Novell NetWare 3.x or 4.x server, or a Windows-based peer server. In all cases, this requirement applies to connections using Microsoft TCP/IP, IPX/SPX-compatible protocol, and NetBEUI in LANs and Transmission Control Protocol/Internet Protocol (TCP/IP) in WANs.

NET–0292. NDIS miniport driver makes only NDIS library calls or WDM system calls

A miniport driver must make calls only to the NDIS library or the WDM system to provide binary compatibility of the driver between Windows Me and Windows 2000.

NET–0293. NDIS 5.0 driver uses Windows 2000 INF file format

All network components must use the INF file format defined in the Windows 2000 DDK.


Network Communications References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

An Interoperable End-to-End Broadband Service Architecture over ADSL System (Version 3.0)

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

ATM User Network Interface (UNI) Specification Version 3.1

Prentice Hall; 1995ISBN 0-13-393828-X
http://www.atmforum.com

Data-Over-Cable Service Interface Specifications (DOCSIS)

Multimedia Cable Network System (MCNS)
http://www.cablemodem.com/

DVB/DAVIC (Digital Video Broadcasting/Digital Audio-Visual Council)

http://www.dvb.org
http://www.davic.org

European Telecommunication Standards Institute (ETSI)

http://www.etsi.org

Handshake procedures for digital subscriber line (DSL) transceivers

http://www.itu.int/

Home Phoneline Networking Alliance Spec, Version 1.0

http://www.homepna.org

Home Radio Frequency Working Group

http://www.homerf.org

IEEE 802.14 Cable TV Working Group

http://www.walkingdog.com/

Infrared Extensions to the NDIS Version 4.0 Functional Specification

http://www.cablemodem.com/

"IP Multicast over Token-Ring Local Area Networks"

RFC 1469
http://www.rfc-editor.org/rfc.html

IrDA specifications

http://www.irda.org

ITU (International Telecommunication Union)

http://www.itu.ch

Network Device Class Power Management Reference Specification, Version 1.0a

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

Preboot Execution Environment (PXE) Specification, Version 2.1

http://developer.intel.com/ial/wfm/wfmspecs.htm

RFC 1469: See "IP Multicast over Token-Ring Local Area Networks."

Shared Wireless Access Protocol (SWAP) Specification, Version 1.1

http://www.homerf.org/tech/

Specification of the Bluetooth System, Volume 2: Profiles, v1.0B

Bluetooth Special Interest Group (SIG)
www.bluetooth.com

STD-201: Extensions to NDIS for Wireless WANs

http://www.pcca.org/standards/standards.htm

Universal Serial Bus Class Definitions for Communication Devices, Version 1.1

http://www.usb.org/developers/devclass_docs.html

U.S. T1 committee Technical Report TR-59, "Single-Carrier Rate Adaptive Digital Subscriber Line (RADSL)"

http://www.t1.org/html/trs.htm

Windows 98 DDK and Windows 2000 DDK

http://www.microsoft.com/ddk/


Checklist for Network Communications

NET–0245. Network adapter uses NDIS 5.0 miniport driver

NET–0246. Adapter automatically senses presence of functional network connection

NET–0247. Adapter automatically senses transceiver type

NET–0248. Adapter can transmit packets from buffers aligned on any boundary

NET–0249. Adapter communicates with driver across any bridge

NET–0250. Networking media supports IP

NET–0251. PCI-based network adapters are bus masters

NET–0252. NDIS 5.0 miniport driver is deserialized

NET–0253. Full-duplex adapter automatically detects and switches to full duplex mode

NET–0254. Adapter supports filtering for at least 16 multicast addresses

NET–0255. Adapter and driver support promiscuous mode

NET–0256. Adapter can be used as a boot device

NET–0257. Network adapter and driver supports priority for IEEE 802-style networks

NET–0258. Internal ISDN device meets PC 2001 network adapter requirements

NET–0259. Internal ISDN device supports synchronous HDLC framing

NET–0260. NDIS interface and driver support raw, unframed synchronous B channel I/O

NET–0261. ISDN driver supports unattended installation, with limitations

NET–0262. ISDN device includes software-selectable terminating resistors

NET–0263. Integrated cable modem meets PC 2001 network adapter requirements

NET–0264. Integrated cable modem exposes an ATM or Ethernet interface

NET–0265. ATM adapter meets PC 2001 network adapter requirements

NET–0266. ATM adapter supports a minimum number of simultaneous connections

NET–0267. ATM adapter supports UBR service type

NET–0268. ATM adapter supports a minimum number of simultaneously active VBR or CBR connections

NET–0269. ATM adapter supports traffic shaping

NET–0270. ATM adapter enforces PCR on UBR virtual circuits

NET–0271. ATM adapter and driver support dynamic link speed configuration

NET–0272. ATM adapter that supports OAM responds to F4 and F5 loopback cells

NET–0273. Integrated ADSL modem meets PC 2001 network adapter requirements

NET–0274. DSL modem supports G.994.1

NET–0275. CAP/QAM ADSL modem supports T1 TR-59

NET–0276. DMT ADSL modem supports G.992.2

NET–0278. Wireless networking media adapters support wireless extensions to NDIS

NET–0279. IEEE 802.11 wireless networking adapters support industry specifications

NET–0280. Infrared device meets PC 2001 network adapter requirements

NET–0281. Infrared device supports both FIR and SIR

NET–0282. IrDA hardware supports unattended driver installation

NET–0283. If implemented, home networking adapter meets PC 2001 network adapter requirements

NET–0284. Network adapter that supports Home RF complies with SWAP specification

NET–0285. If implemented, network adapter that supports HomePNA complies with 1.0 specification.

NET–0286. Plug and Play capabilities support multiple adapters

NET–0287. All resource settings are reported in the user interface

NET–0288. External networking devices support standard control interfaces

NET–0289. Adapter complies with network power management specification

NET–0290. Network device supports wakeup events

NET–0291. Driver works correctly with Microsoft network clients and protocols

NET–0292. NDIS miniport driver makes only NDIS library calls or WDM system calls

NET–0293. NDIS 5.0 driver uses Windows 2000 INF file format


Chapter 15 Printers

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter presents the PC 2001 requirements for printers. The goal of the PC 2001 requirements for printers is to provide the following:

  • A true Plug and Play experience for users, using non-legacy interfaces
  • High-quality color matching between display and color output devices
  • Well-behaved driver and component installation

Unless this chapter defines a specific requirement or exception, all requirements for printers apply as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Basic Printer Requirements

This section summarizes the basic PC 2001 hardware requirements for printers.

PRNT–0294. Device uses USB, IEEE 1394, or network interface port connection

PC 2001 requires the use of a USB, IEEE 1394, or network interface port connection for printers. No proprietary solutions are acceptable; however, other legacy port connections may be present on the device.

USB printers must conform to Universal Serial Bus Device Class Definition for Printing Devices, Version 1.1.

Network printers must meet the requirements in Chapter 14, "Network Communications."

If an IEEE 1284, serial, or IR port connection is included on the printer, that connection must meet the requirements defined in Legacy Plug and Play Guidelines, which contains the requirements for these connections as defined in earlier versions of the system design guide.

PRNT–0295. Network printer supports standard port monitor

Network-connected printers must support TCP/IP standards for Line Printer Remote (LPR) and Line Printer Daemon (LPD) (RFC 1179), Port 9100 printing (raw mode printing), or both types.

PRNT–0296. Device with IEEE 1284.4 capabilities complies with specification

If any device provides IEEE 1284.4 capabilities, the device must comply with the IEEE 1284.4 specification.

PRNT–0297. MFP devices correctly implement multifunction support

If a device—commonly referred to as a multifunction printer (MFP)—contains more than print-only capabilities, then driver support, INF file requirements, device ID, resource allocation, and other Plug and Play capabilities for all functions in the device comply with the requirements defined in Multifunction Print Device Design Guidelines for compatibility with Windows operating systems. This paper is listed in "Printers References."


Device Drivers and Installation for Printers

This section summarizes device driver requirements for printers. The items in this section are requirements for all PC 2001 systems.

PRNT–0298. Printer INF file and installation meet PC 2001 requirements

The manufacturer must provide a printer INF file that installs all printer device components. The manufacturer does not need to supply a printer INF file if a standard printer INF file provided with the operating system can be used.

INF file requirements for MFPs are defined in requirement PRNT–0297, "MFP devices correctly implement multifunction support."

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 98 DDK and Windows 2000 DDK and requirement SYS–0025, "Each device, device driver, and installation of either device or driver meet PC 2001 requirements," in Chapter 3.

Plug and Play IDs must be specific, and INF file [Install] sections must only key off the most specific IDs, as described in the following list.

Plug and Play ID Strings

Protocol | ID string in the printer INF file
USB | Contains &VID and &PID in the ID string
IEEE 1394 | Always specific, with 1394 in the ID string
Parallel port printer | Contains LPTENUM\ in the ID string
USB printer | Contains USBPRINT\ in the ID string
Dot4 printer | Contains DOT4\ in the ID string

For Windows 2000, DEVMODEW structure is defined in "Graphics Driver Structures" of "Common Graphics Driver Interface" in the "Graphics Drivers Reference" of the Windows 2000 DDK.

For Windows Me, DEVMODE structure is defined in "New Function and Structure Reference" of "Printer Driver Overview" in the "Windows 95 Documentation" of the Windows 98 DDK.

PRNT–0299. Driver correctly reports device capabilities

The driver must correctly support the DEVMODE structure as defined in Windows 98 DDK and Windows 2000 DDK.

Required Windows Me support is defined in "Printer INF File Extension" and "Printer-Specific INF File Extensions Reference" in the "Windows 95 Documentation" of the Windows 98 DDK.

Required Windows 2000 support is defined in "Printer Drivers and Spooler Components" of "Graphics Drivers Design Guide" in the Windows 2000 DDK.

PRNT–0300. Driver supports sRGB output or an ICC profile is provided

The device must default either to creating sRGB output or using a vendor-supplied ICC profile.

Windows Me and Windows 2000 support using color profiles that comply with the Specification ICC.1:1998-09 File Format for Color Profiles, listed in "Printers References." The ICM APIs and functionality for Windows Me, Windows 98, and Windows 2000 are defined in the Microsoft Platform SDK, the Windows 98 DDK, Windows Me DDK, and the Windows 2000 DDK. For further information, see the Color Management and Windows Operating Systems Web page, listed in "Printers References."

For color-capable devices that do not default to sRGB output, the vendor must install and associate one or more ICC profiles for ICM. Devices that are sRGB-compliant do not need to provide an ICC profile. The sRGB profile is distributed in Windows Me and Windows 2000 and subsequent releases to these operating systems.

The requirements for sRGB are defined in IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB, listed in "Printers References."

PRNT–0301. Color printer complies with Windows Color Quality Specifications

Color matching capabilities supported in a color printer must comply with the requirements defined in Section 8 of "Windows color quality specifications for printer OEMs," listed in "Printers References." In particular, the following Delta E tolerances must be met for image, graphics, and Pantone patches with default rendering intent:

  • Average Delta E less than or equal to 12 for center colors
  • Average Delta E less than or equal to 20 for device colors
PRNT–0302. Port monitor software meets DDK requirements

Any port monitor or language monitor software provided with a print device must accurately report errors and support bidirectional communication as defined in the Windows 98 DDK and Windows 2000 DDK. The relevant DDK sections are cited in requirement PRNT–306, "Driver supports required DDIs."

PRNT–0303. Driver supports point-and-print network installation

The user must be able to install a driver from a server by double-clicking on the printer share icon.

This capability must accommodate file-number limits and other differences between operating systems that might run on the client and server.

PRNT–0304. Device is available immediately following installation

The user must not have to restart the system after device installation in order to print.

PRNT–0305. Device supports accurate printable regions

The printable regions that can be selected in the user interface must be accurately supported in the actual print output.

PRNT–0306. Driver supports required DDIs

Printer drivers must make sure that print commands from Win32-based applications are executed correctly on the specified printer or plotter. Because these APIs are not hardware specific, each printer driver must interpret the commands for its specific hardware.

For Windows 2000 drivers, the required device driver interfaces (DDIs) are defined in the Windows 2000 DDK. See "Printer Drivers and Spooler Components" in the Windows 2000 DDK.

For Windows Me drivers, this requirement includes correct support of all features advertised for the device, plus required support for Windows features. The required DDIs for Windows Me drivers are listed in the "Printer Driver Overview" in the "Windows 95 Documentation" of the Windows 98 DDK.

PRNT–0307. Printer driver does not run in kernel mode

Printer drivers for Windows 2000 must run only in user mode. Drivers that run in kernel mode can incur stability problems. For driver implementation requirements, see "Choosing User Mode or Kernel Mode" in the DDK, listed in "Printer References."

PRNT–0308. Printer device and driver support Default Device-class Power Management Specification

All printer devices, printer drivers, and supporting components must support the D0 and D3 power states consistent with the Default Device Class Power Management Reference Specification, Version 1.0. Each device must be able to complete successfully a system sleep/wake transition, where the device transitions from D0 to D3 to D0, without losing functionality and without requiring user intervention to restore functionality. System power must be removed in the D3 state.


Printers References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Color Management and Windows Operating Systems Web page

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

Default Device Class Power Management Reference Specification, Version 1.0

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

IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB

http://www.iec.ch

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/legacypnp/

Multifunction Print Device Design Guidelines

http://www.microsoft.com/hwdev/mf/mfp.htm

RFC 1179

http://www.rfc-editor.org/rfc.html

Specification ICC.1:1998-09 File Format for Color Profiles

http://www.color.org/profiles.html

Universal Serial Bus Device Class Definition for Printing Devices, Version 1.1

http://www.usb.org/developers/devclass.html

Windows 98 DDK, Windows Me DDK, Windows 2000 DDK, and Microsoft Platform SDK

http://msdn.microsoft.com/library/default.asp

"Windows color quality specifications for printer OEMs"

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


Checklist for Printers

PRNT–0294. Device uses USB, IEEE 1394, or network interface port connection

PRNT–0295. Network printer supports standard port monitor

PRNT–0296. Device with IEEE 1284.4 capabilities complies with specification

PRNT–0297. MFP devices correctly implement multifunction support

PRNT–0298. Printer INF file and installation meet PC 2001 requirements

PRNT–0299. Driver correctly reports device capabilities

PRNT–0300. Driver supports sRGB output or an ICC profile is provided

PRNT–0301. Color printer complies with Windows Color Quality Specifications

PRNT–0302. Port monitor software meets DDK requirements

PRNT–0303. Driver supports point-and-print network installation

PRNT–0304. Device is available immediately following installation

PRNT–0305. Device supports accurate printable regions

PRNT–0306. Driver supports required DDIs

PRNT–0307. Printer driver does not run in kernel mode

PRNT–0308. Printer device and driver support Default Device-class Power Management Specification


Chapter 16 Digital Still Image Peripherals

IMPORTANT: The requirements in this guide provide instructions for designing PC systems that will result in an optimal user experience with typical Windows-based applications running under either the Microsoft Windows Millennium Edition or Windows 2000 Professional or later operating systems. These design requirements are not the basic system requirements for running any version of Windows operating systems.

This chapter presents the PC 2001 requirements for digital still image peripherals, including but not limited to digital cameras and scanning devices such as sheet-fed, flatbed, handheld, and film scanners.

Unless this chapter defines a specific requirement or exception, all requirements for digital still image peripherals apply as presented in Chapter 3, "PC System," and Chapter 6, "Buses and Interfaces."


Digital Still Image Devices Basic Requirements

This section summarizes the basic PC 2001 hardware requirements for scanners and digital cameras.

IMAG–0309. Digital still camera uses PC 2001 compatible port connection with USB or IEEE 1394 connection

PC 2001 must use either USB or IEEE 1394 port connections for digital still cameras. Other port connections may be present on the device, if these port connections meet PC 2001 requirements.

IMAG–0310. Driver supports sRGB output or an ICC profile is provided

The device must default either to creating sRGB output or using a vendor-supplied ICC profile.

Windows Me and Windows 2000 support using color profiles that comply with the Specification ICC.1:1998-09 File Format for Color Profiles. The ICM APIs and functionality for Windows Me and Windows 2000 are defined in the Microsoft Platform SDK, the Windows Me DDK, and the Windows 2000 DDK. For more information, see the Color Management and Windows Operating Systems Web page, listed in "Digital Still Image Peripherals References."

For color-capable devices that do not default to sRGB output, the vendor must install and associate one or more ICC profiles for ICM. Devices that are sRGB compliant do not need to provide an ICC profile. The sRGB profile is distributed in Windows Me and Windows 2000 and will be in subsequent releases of these operating systems.

The requirements for sRGB are defined in IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB.

IMAG–0311. USB device meets USB imaging device class specifications

All USB hardware must comply with the requirements defined in Chapter 6, "Buses and Interfaces," which includes the USB specifications for specific device types.

Compliance with the following two specifications from the USB Imaging Class Device Working Group requires explanation, as follows:

  • The USB Still Image Capture Device Definition Specification applies to both digital still cameras and scanners. Compliance becomes a requirement for PC 2001 within 90 days of when the revision number of the specification reaches version 1.0.
  • The USB Imaging Class Specification will contain requirements for still images produced by scanners. The USB digital still camera specification is based on the draft for PIMA 15740:2000 Photography – Electronic still picture imaging – Picture Transfer Protocol (PTP) for Digital Still Photography Devices.
IMAG–0312. Still image devices meet minimum throughput requirements

Still image devices must download images to the PC and make them available through WIA to applications at no less than the following rates:

  • Fast IR at 80 Kpixels/s
  • USB at 120 Kpixels/s
  • IEEE 1394 at 200 Kpixels/s

For more information on WIA, see the Windows Image Acquisition Web page, listed in "Digital Still Image Peripherals References."

IMAG–0313. Digital camera uses PC-compatible file system for removable storage

For devices that include removable flash memory, the memory must use one of the following PC-compatible file systems:

  • Media integrates an ATA controller.
  • Device file system installs via the Windows 2000 Professional Installable File System.
  • Device ships with a Windows Media Device Manager (WMDM) pluggable service provider.
IMAG–0314. Digital camera stores images in JPEG-compressed file format

A digital still camera must provide the user with the option to store images in a JPEG-compressed format.

IMAG–0315. Still image devices deliver accurate image information

Imaging devices must resolve at least 1/4 line per claimed pixel resolution in both the horizontal and the vertical direction to ensure greater image capture accuracy. This requirement applies to the device’s best quality setting.


Plug and Play for Digital Still Image Devices

The items in this section are requirements for Plug and Play capabilities. For Plug and Play requirements related to parallel ports, see the Legacy Plug and Play Guidelines.

IMAG–0316. USB camera firmware supports PIMA 15740 protocol

PIMA 15740 defines a common protocol for all digital still cameras, ensuring PC connectivity using a generic driver provided with the Windows operating system. This protocol is supported by imaging industry leaders. PIMA 15740 provides interoperability of digital still cameras, including PC and peer-to-peer connectivity.

For information, see the draft for PIMA 15740.

Note: A USB camera does not need to supply a WIA driver if the camera firmware supports PIMA 15740.


Device Drivers and Installation for Digital Still Image Devices

This section summarizes the device driver requirements for scanners and digital still image devices.

IMAG–0317. Driver support implements the WIA driver architecture

Still image devices must provide drivers based on WIA that expose camera properties and enable camera functionality. The services provided by WIA provide hardware abstraction, installation wizards, and event polling.

WIA is both an API and a DDI for Windows operating systems. WIA provides a mechanism to enumerate available image acquisition devices, both local and remote.

WIA architecture is defined in the "Still Image Drivers" section of the Windows 2000 DDK. For related information, see the Windows Image Acquisition Web page, listed in "Digital Still Image Peripherals References."

Note: The IR bus interface is exempt from this requirement.

IMAG–0318. Digital still cameras that stream video require WDM Stream class drivers

Cameras capable of streaming video while tethered to the PC must provide a WDM minidriver based on WDM stream class support.

WDM stream class support is defined in the "Kernel-mode Drivers for Still Image Devices" section of the Windows 2000 DDK.

IMAG–0319. If TWAIN datasources are provided, device driver supports TWAIN 1.7

For devices with a TWAIN datasource, the device driver must support the TWAIN Specification, Version 1.7, ensuring that the device can run without a hardware-specific user interface and download n number of images at a single time.

IMAG–0321. Scanners with an IEEE 1394 interface uses SBP2Port

SBP2Port.sys is the IEEE 1394 transport driver in the Windows Me and Windows 2000 operating systems. It provides transport services for SCSI-like commands over IEEE 1394. Scanners must use SBP2Port to communicate over IEEE 1394 if converting the device from a SCSI or SCSI-like interface.

Implementation details for bus-specific transfer protocols are defined in the "Storage Driver Architecture" section of the Windows 2000 DDK.


Digital Still Image Peripherals References

Following are the references, services, and tools cited in this chapter that are available to help build hardware that works optimally with Windows operating systems.

Color Management and Windows Operating Systems Web page

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

IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB

http://www.iec.ch

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/LegacyPnP/

PIMA 15740:2000 Photography – Electronic still picture imaging – Picture Transfer Protocol (PTP) for Digital Still Photography Devices

http://www.pima.net/standards/it10/IT10_POW.htm#15740

Plug and Play specifications

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

Specification ICC.1:1998-09 File Format for Color Profiles

International Color Consortium (ICC)
http://www.color.org

TWAIN Specification, Version 1.7

http://www.twain.org/docs/

Universal Serial Bus Specification, Revision 1.1

http://www.usb.org/developers/docs.html

USB Still Image Capture Device Definition Specification
USB Imaging Class Specification

http://www.usb.org/developers/docs.html
http://www.usb.org/developers/devclass_docs.html#approved

Windows Image Acquisition Web page

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

Windows 98 DDK, Windows Me DDK, Windows 2000 DDK, and Microsoft Platform SDK

http://msdn.microsoft.com/library/default.asp


Checklist for Digital Still Image Peripherals

IMAG–0309. Digital still camera uses PC 2001 compatible port connection with USB or IEEE 1394 connection

IMAG–0310. Driver supports sRGB output or an ICC profile is provided

IMAG–0311. USB device meets USB imaging device class specifications

IMAG–0312. Still image devices meet minimum throughput requirements

IMAG–0313. Digital camera uses PC-compatible file system for removable storage

IMAG–0314. Digital camera stores images in JPEG-compressed file format

IMAG–0315. Still image devices deliver accurate image information

IMAG–0316. USB camera firmware supports PIMA 15740 protocol

IMAG–0317. Driver support implements the WIA driver architecture

IMAG–0318. Digital still cameras that stream video require WDM Stream class drivers

IMAG–0319. If TWAIN datasources are provided, device driver supports TWAIN 1.7

IMAG–0321. Scanners with an IEEE 1394 interface uses SBP2Port


Part 4 Appendixes

Appendix A Resource Mapping

This appendix summarizes assignments for IRQ, DMA, and I/O port addresses used by built-in devices on legacy system boards. This appendix also includes details about required interrupts for legacy-free PC 2001 systems.

ISA Interrupts

Some IRQ assignments are fixed as specified in the table below. Any interrupt assignment that is not considered fixed is available for reassignment by the system.

For legacy-free systems, some unused IRQs are reserved, since there is no way for them to be used by another system function. Unused and reserved IRQs should be enabled and unmasked in the Programmable Interrupt Controller (PIC), and they must not be connected to an active signal source.

ISA Interrupts

Hardware IRQ | Legacy-reduced system | Legacy-free system
IRQ 0 | System timer | System timer
IRQ 1 | Keyboard | Keyboard for mobile or reserved.
IRQ 2 | Second PIC cascade | Second PIC cascade
IRQ 3 | COM 2 | Not considered fixed
IRQ 4 | COM 1 | Not considered fixed
IRQ 5 | Sometimes LPT 2—not considered fixed | Not considered fixed
IRQ 6 | FDC | Not considered fixed
IRQ 7 | LPT 1 | Not considered fixed
IRQ 8 | Real-time clock/CMOS | Real-time clock/CMOS
IRQ 9 | Not considered fixed | Not considered fixed
IRQ 10 | Sometimes COM 4—not considered fixed | Not considered fixed
IRQ 11 | Sometimes COM 3—not considered fixed | Not considered fixed
IRQ 12 | PS/2-style mouse | Not considered fixed or integrated pointing device for mobile
IRQ 13 | Coprocessor | Coprocessor
IRQ 14 | Primary IDE controller | Primary IDE controller
IRQ 15 | Secondary IDE controller | Secondary IDE controller


Legacy ISA DMA Assignments

Legacy-reduced PCs are permitted to use ISA DMA channels 2 and 3 for the functions specified in the table below. Legacy-free PCs are not permitted to use any ISA DMA channels.

Legacy ISA DMA Considered Fixed

Hardware DMA | System function (default)
DMA 0 | ISA expansion devices. Reserved. Do not use.
DMA 1 | ISA expansion devices. Reserved. Do not use.
DMA 2 | FDC
DMA 3 | Extended capabilities port (ECP) parallel port on LPT 1.
DMA 4 | DMA controller cascading. Do not use.
DMA 5 | ISA expansion devices. Reserved. Do not use.
DMA 6 | ISA expansion devices. Reserved. Do not use.
DMA 7 | ISA expansion devices. Reserved. Do not use.


Legacy ISA I/O Address Assignments

The following table lists I/O addresses that are used by legacy ISA devices and are 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 interface1
0220–022F | Sound Blaster1
0278–027A | LPT 2 (XT parallel port 3)1
02E8–02EF | Alternate COM (4)1
02F8–02FF | COM 21
0330–0331 | MPU-4011
0376 | IDE Controller
0378–037A | LPT 1 (XT parallel port 2)1
0388–038B | FM synthesis
03B0–03BB | MDA, EGA/VGA
03BC–03BE | LPT 3 (XT parallel port 1)1
03C0–03DF | EGA/VGA
03E0–03E7 | PCIC PCMCIA controllers
03E8–03EF | Alternate COM (3)1
03F0–03F7 | FDC—excluding 03F61
03F8–03FF | COM 11
0534–0537 | Windows Sound System-compatible
0CF8–0CFB | PCI ports
1 These addresses are restricted and must not be used by PC 2001 legacy-free systems. Processor reads of the byte addresses in the shaded rows of this table must return FFH.


Required Interrupts for PC 2001 Legacy-Free Systems

The following table lists required interrupts for PC 2001 legacy-free systems.

Required Interrupts for PC 2001 Legacy-Free Systems

Interrupt

Description

INT 8 (IRQ 0)

System timer. Used to keep the time-of-day clock updated.

INT 9

INT 9 is invoked only by software and does not use IRQ 1 signaling. However, for proper system operation, this handler must perform the same operations as on legacy systems, which are:

The interrupt handler needs to be in the IVT chain for INT 9.

IRQ 1 is unmasked at the PIC.

The INT 9 handler required in the BIOS is exactly the same as that which is required in systems that contain legacy components. This handler is not intended for use during the boot process, it is available to help support legacy applications running in Microsoft MS-DOS Virtual Machines (MS-DOS-boxes).

For backward compatibility with MS-DOS applications, Windows Me implements a complete "Virtual" keyboard controller and passes all keyboard traffic through it regardless of whether it is from a real keyboard controller or a USB keyboard. This allows both Win16 applications and MS-DOS-based applications to continue to function. In order to support legacy applications in MS-DOS Virtual Machines, the command interpreter must behave the same as on a legacy system, which requires the full INT 9 support provided by legacy systems. This handler handles input from port 60h, passes it off to INT 15h / AH= 4Fh, stores the data in the keyboard buffer of the BIOS Data Area, and updates the flags. The following provides reference code for the required capabilities:

push es
push ds
push a
push f
mov ax, 40h
mov es,ax
mov ax, <segment of translation table>
mov ds,ax
xor bx, bx
in al, 60h
mov ah, 4Fh
int 15h
jnc SkipProcess
mov bl,al
shl ax, 8
mov al, ds:[bx]
mov bx, es:1ah
mov es:[bx]
inc bx
inc bx
mov es:1ah, bx
mov al, 61h
out 20h, al

SkipProcess:

 popf

 popa

 pop ds

 pop es

 iret

INT 10

Set video mode.

INT 11

Equipment determination.

If there are devices that appear as FDDs (for example, El Torito capable CD-ROM devices), then:

Bit Mask 0x0001 (bit 0) in AL must be set.

Bits 6 and 7 must properly indicate the number of FDD devices and devices that appear as floppy disk devices.

If there are no devices that appear as FDDs, then:

Bit mask 0x0001 (bit 0) must be clear.

Bits 6 and 7 must be set to 0.

INT 13

High-capacity drive support.
All subfunctions, including AH = 40h–48h.

Disk operation notes:

ROM BIOS must set the head settle, motor start, and format gap values in the disk table pointed to by interrupt vector 1Eh.

Implement the INT 13h AH = 17h call, that is, set the DASD type for format.

Support the change line (INT 13h AH = 15h) on INT 13h FDDs.

Support INT 13h AH = 8 (Get device parameters).

Implement the extended INT 13h services (AH functions 41h – 48h).

For INT 13h with AH = 48h for installed FDDs:

If there are no FDDs attached as INT 13h devices, INT 13h AH = 48h must fail for all floppy drive numbers (drive 0, in particular). However, INT 13h AH = 8 on drive number 0 (DL=0) must work even if there are no INT 13h FDDs, and it must return a FDD count of 0 in the DL register to indicate that no FDDs are present.

If a FDD is an industry-standard 1.44-MB, 3.5-inch drive, the INT 13h AH = 8 call on the device should not modify the BL register.

If the device is something other than an industry-standard 1.44-MB, 3.5-inch drive, but is media compatible with the 1.44-MB floppy standard, the INT 13h AH = 8 call on the device should return the parameters for a 1.44-MB industry-standard floppy disk drive but set the BL register to 10h and return the true maximum-supported capacity drive parameters on the INT 13h AH = 48h call.

For floppy devices that are not media compatible with the 1.44-MB floppy standard, the INT 13h AH = 8 call should return the closest reasonable parameters, set the BL register to 10h, and return the true maximum supported capacity parameters on the INT 13h AH = 48h call.

The INT 13h AH = 8 (Get device parameters) call must not turn on the drive motor for FDDs.

INT 15

The following subfunctions are required:

AH
    C0     Get configuration
    4F     Translate keyboard scan code
    87     Copy extended memory
    88     Get extended memory size

AX
    C2xx     Mouse functions
    E820     Get system memory map
    E801     Get memory size

Function 4Fh is expected to pass all keys from the keyboard, and respect the status of the carry flag on return. The HID key codes from USB keyboards must be translated to PS/2 key codes for backward compatibility with other key filters. All keyboards must be supported, including-but not limited to-101/102 key English, 105 key European, 106 and 109 key Japanese. HID to PS/2 translation tables are available at: http://www.pcdesguide.org/documents/keycode.htm

INT 16

The following subfunctions are required:

AH
    00h     Get keystroke
    01h     Check for keystroke
    02h     Get control keys
    10h     Get enhanced keystroke

    11h     Check for enhanced keystroke
    12h     Get control keys for enhanced keyboard

INT 19

Bootstrap loader

INT 1A

The following subfunctions are required:

AH    0x     RTC

AX    B1xx     PCI BIOS

INT 1B

CTRL+Break Handler

INT 23

CTRL+C, CTRL+Break Handler


Appendix B Remote Lockout

This appendix provides supporting information for requirement BIOS-0014.5, "System BIOS provides remote lockout capability."

Initial Conditions

The initial state of the RLI setting after the power is turned on, cold boot, or warm boot is all events are enabled. Management software uses this interface to lock out events. Management software should re-enable events when sensitive operations have been completed.

Invocation and Parameter Passing

The RLI is only available in real mode and is invoked using INT 15H. All parameters are passed to and from the RLI functions using processor registers. The AH register is set to 25H for the RLI, and the AL register indicates the desired RLI function.

The AX, BX CX, DX, SI, and DI registers may be altered by the RLI. Management software should save these registers before calling RLI functions and restore them on return (after retrieving any parameters returned by the RLI). All other processor registers are preserved.

If the function is successful, the RLI function returns with the carry flag (CF) reset and the AH register set to zero.

If an error is encountered, the RLI function returns with CF set and AH set to:

86hERR_FUNCTION_NOT_SUPPORTED

The RLI supports three functions:

  • Inquire Lockout Capabilities
  • Get Remote Lockouts
  • Set Remote Lockouts

All of the RLI functions use a bitmap to describe lockouts. Inquire Lockout Capabilities and Get Remote Lockouts return this bitmap. Set Remote Lockout uses this bitmap to select events to lock out. The bits are numbered from zero to 15 with the right-most bit being the least significant and bit 0. At a minimum, bits 1, 2, 4, and 5 in the Lockout Bitmap must be supported. The Lockout Bitmap is shown in the following table.

Lockout Bitmap

Bit | Definition
0 | Permanently reserved.
1 | Soft on/off switch. Controlled via ACPI power-button interfaces.
2 | Reset button.
3 | Mouse.
4 | CTRL+ALT+DEL key combination.
5 | All keyboard activity except CTRL+ALT+DEL.
6–15 | Reserved for future use. Reset to zero for backward and forward compatibility.


Inquire Lockout Capabilities (00H)

This function returns the lockout capabilities of the system. The bit-mapped value returned in the CX register indicates the lockouts managed by the RLI. All return values are static. This function always returns the same values. The current lockout setting does not affect the value returned by this function.

Input

[AX] = 2500H

Output

[CF] = status

Set = error

Reset = success

[AH] = Return code, if [CF] set, then error code

86h ERR_FUNCTION_NOT_SUPPORTED

If [CF] reset,

[AH] = Zero (00)

[BX] = Revision (BCD-encoded with an implied decimal point between the bytes; for example, 0110H is 1.10

[CX] = Lockout capabilities (see Lockout Bitmap table)

If bit set, event lockout supported

If bit reset, event lockout not supported

Example

MOV | AX, 2500H | ; Inquire Lockout Capability
MOV | BX, 0 | ; Clear output registers
MOV | CX, 0 |
INT | 15H | ; Able to get capabilities?
JC | ERROR | ; No, error out
MOV | wRevision, BX | ; Yes, save interface revision
MOV | wCapabilities, CX | ; and system lockout capabilities


Get Remote Lockouts (01H)

This function returns the current lockout setting. The bit-mapped value returned in the CX register indicates which events are enabled and which events are locked out.

Input

[AX] = 2501H

Output

[CF] = status

Set = error

Reset = success

[AH] = Return code, if [CF] set, then error code

86h ERR_FUNCTION_NOT_SUPPORTED

If [CF] reset,

[AH] = Zero (00)

[CX] = Current lockout setting for all supported events (see Lockout Bitmap table)

If bit set, event locked out

If bit reset, event enabled (or unsupported)

Example

MOV | AX, 2501H | ; Get Remote Lockouts
MOV | CX, 0 | ; Clear output registers
INT | 15H | ; Able to get remote lockouts?
JC | ERROR | ; No, error out
MOV | wInitialSetting, CX | ; Save initial setting
TEST | CX, 4 | ; Is Reset event locked out?
JZ | RESET_ENABLED | ; No, continue ; Yes

Comments: Only supported events are reported. Attempts to lock out unsupported events are not reflected in the Lockout Bitmap returned by this function. Only bits for supported events are ever set in the Lockout Bitmap.


Set Remote Lockouts (02H)

This function locks out or enables the specified events. The bit-mapped value passed in the CX register indicates which events to allow and which events to lock out.

Input

[AX] = 2502H

[CX] = Desired lockout setting (see Lockout Bitmap table)

If bit set, requests that the event be locked out

If bit reset, requests that the event be enabled

Output

[CF] = status

Set = error

Reset = success

[AH] = Return code, if [CF] set, then error code

86h ERR_FUNCTION_NOT_SUPPORTED

If [CF] reset,

[AH] = Zero (00)

Example

MOV | AX, 2502H | ;Set Remote Lockouts
MOV | CX, 2 | ;Disable Soft On/Off events, enable all others
INT | 15H | ;Able to set remote lockouts
JC | ERROR | ;No, error out

Comments: If supported, this request always succeeds. Requesting lockout of an unsupported event is not an error. The interface simply ignores the request for that event and sets supported events as requested (locked out or enabled).


Appendix C PC 2001 Master Checklist

This appendix lists all requirements in PC 2001, including cross-references to related requirement numbers published in PC 99 System Design Guide.

Requirement numbering has evolved since the original design guide. In PC 2001, requirement identifiers are assigned according to an alphanumeric scheme. Each requirement has a permanent mnemonic and number combination, as follows:

mnemonic––item number.subitem

The mnemonic is a shorter version of the name for a technology. The following mnemonics are used in this edition of the system design guide:

Label | Reference
1394 | IEEE 1394 bus
ATA | ATA and ATAPI interface
AUD | Audio technology
BTH | Bluetooth
BIOS | BIOS
CBUS | PCCard and CardBus
GRPH | Graphics adapters and controllers
IMAG | Imaging
INPT | Input devices
MOBL | Mobile computer
MOD | Modems
MON | Monitor technology
NET | Network connectivity
PCI | PCI bus
PCIX | PCI-X
PRNT | Printers
SCSI | Small Computer System Interface (SCSI)
SMRT | Smart Card
STOR | Storage devices and controllers
SYS | PC system
USB | USB bus
VID | Video technology
WORK | Workstation computer

The item number is an arbitrarily assigned, sequential number up to 4 digits with leading zeros. These numbers are determined by order of creation. Numbers are retired with an obsolete guideline and not reassigned. The subitem is a single-digit number to itemize any subguidelines.

Number | PC 99 | Requirement Statement
SYS–0001 | 3.1 | System performance meets PC 2001 minimum requirements
SYS–0001.1 | 3.1.1 | System includes CPU and cache that meets PC 2001 minimum requirements
SYS–0001.2 | 3.1.2 | System memory meets PC 2001 minimum requirements
SYS–0054 | 4.5 | If implemented, system memory includes ECC memory protection
SYS–0001.3 | 3.1.3 | APIC implemented and properly connected
SYS–0002 | 3.2 | System design meets ACPI 1.0b specification and PC 2001 requirements
SYS–0002.1 | 3.2.2 | System supports S3, S4, and S5 states
SYS–0002.3 | 3.2.5 | System provides no user-accessible method for disabling ACPI in the BIOS
SYS–0002.4 | 3.2.6 | If software fan control is implemented, thermal design and fan control comply with ACPI 1.0b
SYS–0002.5 | 3.2.7 | All system-board power management or Plug and Play features comply with ACPI 1.0b
SYS–0003 | 3.3 | Hardware design supports OnNow and Instantly Available PC initiatives
SYS–0003.1 | 3.3.1, 3.7 | System and devices appear as off in the sleep state
SYS–0003.2 | 3.3.2 | System provides one or more indicators to show whether the system is in the working or sleep state
SYS–0003.3 | 3.3.3 | System provides software-controlled, ACPI-based power switch
SYS–0003.4 | 3.3.4 | Each device and bus supports the power management specifications for its class
SYS–0003.5 | 3.3.5 | System power supply provides standby power for system wakeup events
BIOS–0004 | 3.4 | BIOS meets PC 2001 requirements for OnNow and Instantly Available PC support
BIOS–0004.1 | 3.4.1 | BIOS supports Fast POST (S4, S5, or mechanical off)
BIOS–0004.2 | 3.4.2 | Resume from sleep state (S1-S3) to operating system handoff occurs within 1 second
BIOS–0005 | 3.5 | BIOS includes local boot support
BIOS–0005.1 | 3.5.2 | BIOS supports booting the system from CD or DVD
BIOS–0005.2 | 3.5.7 | BIOS provides boot support for USB keyboards and hubs
BIOS–0005.3 |  | BIOS handles long descriptors read from USB device attached at boot time
BIOS–0005.4 | 3.49 | Operating system recognizes the boot drive in a multiple-drive system
BIOS–0005.5 |  | System timer is supported at system boot
BIOS–0006 | 3.55 | BIOS supports SMBIOS 2.3
BIOS–0007 | 3.5.4 | BIOS and CMOS properly accommodate dates
BIOS–0008 | 3.5.5 | BIOS supports security
BIOS–0009 | 3.5.6 | BIOS supports BIOS updates and revisions
BIOS–0010 | 3.5.8 | System BIOS supports debug port
BIOS–0011 | 3.45 | System BIOS and option ROMs support Int 13h Extensions
BIOS–0012 |  | ROM BIOS interrupt handlers preserve values in all registers
BIOS–0014 | 3.5.3 | BIOS supports remote boot
BIOS–0014.1 | 3.5.1 | BIOS supports PXE
BIOS–0014.2 | 3.5.3 | BIOS supports booting the system from the network and using F12 to force a system boot
BIOS–0014.2.1 | 3.5.3 | BIOS allows boot devices to be configured in order of precedence for boot
BIOS–0014.2.2 | 3.5.3 | Interface clearly shows boot order when users make configuration choices
BIOS–0014.2.3 | 3.5.3 | F12 key forces a system boot initiated from the network adapter
BIOS–0014.3 | 3.5.1 | System UUID is provided in print
BIOS–0014.4 |  | BIOS supports BIS
BIOS–0014.5 |  | System BIOS provides remote lockout capability
BIOS–0015 |  | BIOS supports ACPI legacy-free reporting mechanism
BIOS–0016 | 9.14 | BIOS does not configure I/O systems to share PCI interrupts
BIOS–0017 | 9.15 | BIOS configures boot device IRQ and writes to the interrupt line register
BIOS–0018 | 10.6 | System BIOS supports ATA
BIOS–0019 | 10.11 | BIOS enumeration of all ATAPI devices complies with ATA/ATAPI-5
SYS–0020 | 3.8 | System and component design practices follow accessibility requirements
SYS–0021 | 3.25 | PC 2001 system includes USB with two user-accessible USB ports, minimum
SYS–0022 | 3.26 | If IEEE 1394 is implemented, all components meet PC 2001 requirements
SYS–0023 | 3.27 | System buses meet PC 2001 requirements
SYS–0024 | 12.1-12.23 | If CardBus is implemented, all components meet PC 2001 guidelines
SYS–0025 | 3.11 | Each device, device driver, and installation of either device or driver, meet PC 2001 requirements
SYS–0025.1 | 3.16.1 | Driver installation does not interfere with other devices
SYS–0025.2 | 3.16.2 | Devices with WDM support in Windows include WDM-based drivers
SYS–0025.3 | 3.16.3 | Driver supports Plug and Play and power management IRPs
SYS–0025.4 | 3.16.4 | All configuration settings are stored in the registry
SYS–0025.5 | 3.16.5 | All INF and other file information is correct
SYS–0025.6 | 3.16.6 | Installation uses methods defined in the DDK
SYS–0026 | 3.12 | Each bus and device meets Plug and Play specifications
SYS–0027 | 3.13 | Unique Plug and Play device ID provided for each system device and add-on device
SYS–0029 | 3.17 | Minimal user interaction needed to install and configure devices
SYS–0029.1 | 3.17.1 | The device is immediately functional without restarting the system
SYS–0029.2 | 3.17.2 | Software settings are available for configuring all resources
SYS–0029.3 | 3.17.3 | Dynamic disable capabilities are supported for all devices
SYS–0030 | 3.19 | Hot-plugging capabilities for buses and devices meet PC 2001 requirements
SYS–0030.1 | 3.19.1 | USB, IEEE 1394, and PC Card devices and buses support hot-plugging
SYS–0030.2 | 3.19.2, 9.16 | System supports hot-plugging for any PCI devices that use ACPI-based methods
SYS–0030.3 | 3.19.3 | All removable media support media status notification
SYS–0030.4 | 3.38 | If implemented, system supports smart card specifications
SYS–0031 | 3.20, 19.37 | If implemented, Device Bay components comply with Device Bay 1.0
SYS–0032 | 3.21 | Multifunction device meets PC 2001 device requirements for each device
SYS–0032.1 | 3.21.1 | Each enumerated device has a unique device ID
SYS–0032.2 | 3.21.2 | Windows can separately access and configure each logical device
SYS–0032.3 | 3.21.3 | Each enumerated device meets its own resource requirements
SYS–0032.4 | 3.21 (PC99A)* | For PC 2001, separate drivers are required for separate functions
SYS–0032.5 |  | There are no start order dependencies between drivers for separate functions
SYS–0032.6 |  | Independent functions and devices can be used concurrently, with no hidden dependencies
SYS–0032.7 |  | Each function and device can be power managed independently
SYS–0033 | 3.24 | Each bus meets written specifications and PC 2001 requirements
SYS–0034 |  | If implemented as an industry-standard riser card, the riser device subsystem complies with applicable standard Plug and Play requirements
SYS–0035 | 3.41 | If DVD-Video playback is implemented, PC 2001 system provides video playback capabilities
SYS–0036 | 3.43 | If video capture is implemented, analog video input and capture capabilities comply with PC 2001 requirements
SYS–0037 |  | If Digital Video Interface is implemented, components comply with PC 2001 requirements
SYS–0038 | 3.48 | PC 2001 system includes hard disk and controller
SYS–0039 | 3.34 | PC 2001 system includes either CD or DVD drive and controller
SYS–0041 | 3.28 | System does not include ISA expansion devices or slots
SYS–0042 |  | Preinstalled components and upgrades do not require MS-DOS or legacy interfaces
SYS–0067 | 3.50 | Secondary boot and upgrade capability is independent of FDC-based floppy disk drive
BIOS–0043 |  | BIOS supports required interrupts
BIOS–0013 |  | BIOS supports legacy removal
BIOS–0045 |  | No legacy ports detected
SYS–0040 | 3.50 | If implemented, floppy disk capabilities do not use legacy FDC
SYS–0047 |  | A20M# is always de-asserted (pulled high) at the processor
SYS–0046 |  | System supports legacy-free debug capabilities
SYS–0048 | 3.51 | System supports WHIIG
SYS–0049 | 3.54 | Expansion devices on desktop systems can be remotely managed
WORK–0051 | 4.1 | Workstation system components meet minimum performance requirements
WORK–0051.1 | 4.2 | System CPU speed is 700 MHz, minimum
WORK–0051.2 | 4.2 | System has 256 KB of cache per processor, minimum, present and enabled
WORK–0051.3 | 4.2 | System memory is 128 MB RAM, minimum
WORK–0051.4 | 4.4 | RAM must be capable of expansion to 2 GB, minimum
WORK–0052 | 4.3 | If implemented as a multiple processor system, the system must meet PC 2001 requirements
WORK–0052.1 | 4.3 | The system must employ those processors symmetrically
WORK–0052.2 | 4.3 | Each processor must have a separate cache
WORK–0052.3 | 4.5 | The system memory and external processor cache are protected with error correction code (ECC) memory protection
WORK–0052.4 | 4.3 | The system must comply with the ACPI 1.0b specification
WORK–0055 |  | If implemented as a 64-bit system, PCI bus, bridges, and adapters support DAC command
WORK–0056 | 4.8 | Workstation supports 64-bit I/O bus architecture if system includes 64-bit processors
SYS–0058 |  | For 64-bit platforms, each device and driver meets PC 2001 device requirements
WORK–0059 | 4.10 | Graphics subsystem supports workstation performance demands
WORK–0059.1 |  | Workstation screen resolution meets minimum requirements
WORK–0059.4 |  | If implemented, an AGP Pro Bus follows the AGP Pro 1.1 specification
WORK–0060 | 4.12 | If implemented, multiple hard-drive system meet workstation PC 2001 performance requirement
PCIX–0129 |  | If the workstation implements PCI-X, system and components comply with PCI-X 1.0
MOBL–0061 | 6.1 | Mobile PC performance meets Mobile PC 2001 minimum requirements
MOBL–0061.1 | 6.1 | Minimum 400 MHz processor
MOBL–0061.2 | 6.1 | Minimum 128 KB of cache, present and enabled
MOBL–0061.3 | 6.1 | 64 MB of RAM, minimum
MOBL–0062 | 6.2 | Mobile PC supports Smart Battery or ACPI Control Method battery
MOBL–0062.1 | 6.2.1 | If implemented, Smart Battery meets PC 2001 requirements
MOBL–0062.2 | 6.2.2 | If implemented, ACPI Control Method Battery meets PC 2001 requirements
MOBL–0063 | 6.5 | Mobile PC includes at least one USB port
MOBL–0064 | 6.7 | If implemented, Mobile PC includes compliant IEEE 1394
MOBL–0065 | 6.8 | Mobile PC includes CardBus
MOBL–0066 | 6.9 | Mobile PC keyboard and pointing device meet PC 2001 Mobile requirements
MOBL–0069 | 6.18, 6.22 | Mobile PC meets PC 2001 Mobile graphics and video requirements
MOBL–0069.1 |  | Mobile PC has integrated display
MOBL–0069.2 |  | Mobile PC provides PC 2001 Mobile graphics capabilities
MOBL–0069.3 | 6.21 | If implemented, extrnal video connector meets mobile PC requirements
MOBL–0069.4 | 6.24 | If implemented, TV output meets mobile PC requirements
MOBL–0070 |  | Mobile PC includes PC 2001 hard disk as primary boot device
MOBL–0071 | 6.13 | Communications capabilities meet Mobile PC 2001 requirements
MOBL–0072 | 6.16 | If implemented, CD or DVD drive meets PC 2001 requirements
MOBL–0073 | 6.28 | Docked mobile PC has the ability to identify the specific model of the dock and to uniquely identify the dock itself
MOBL–0074 | 6.30 | Docked mobile PC combination meets PC 2001 Mobile requirements
MOBL–0075 |  | Docking station includes driver support
MOBL–0076 | 6.33 | Docked mobile PC meets PC 2001 BIOS requirements
MOBL–0077 |  | Pre-PC 2001 docking station requirements
MOBL–0078 | 6.32 | Mobile/docking station interface uses ACPI-defined mechanisms
MOBL–0079 | 6.34 | Docking station supports warm docking
MOBL–0080 | 6.35 | Docking system supports fail-safe docking
USB–0081 | 7.1, 7.3, 7.6, 7.8 | USB system hardware and devices comply with USB specifications
USB–0084 | 7.5 | USB devices and drivers support maximum flexibility of hardware interface options
USB–0084.1 | 7.5.1 | Devices and drivers provide multiple alternate settings
USB–0084.2 | 7.5.2 | Devices and drivers must not use isochronous bandwidth for alternate setting 0
USB–0085 | 3.2.4, 7.7 | USB host controller and devices can wake the system
USB–0086 | 7.9 | USB hubs are self-powered
USB–0087 | 7.10 | USB bus, controllers, and devices comply with USB power management requirements
USB–0088 | 7.11 | USB devices and drivers meet requirements in related USB device class specification
USB–0089 |  | USB devices install without preloading software
1394–0090 | 8.1 | System implementing IEEE 1394 supports mandatory features in IEEE 1394 standards
1394–0090.1 | 8.1 | System provides IEEE 1394-1995/1394a interconnectivity
1394–0090.2 | 8.1 | Systems implementing IEEE 1394 internal devices support mandatory features in the IEEE 1394a-2000 or IEEE P1394b amendments to IEEE 1394-1995
1394–0091 | 8.2 | Host controller supports mandatory components of 1394 OHCI 1.1
1394–0092 | 8.4 | Host controller supports minimum peak data rates specified in IEEE 1394 standards
1394–0093 | 8.24 | If the IEEE 1394 implementation provides external connectivity, system must use only sockets specified by IEEE 1394-1995 and its amendments
1394–0094 | 8.6 | Device command protocols conform to standard device class interfaces
1394–0095 | 8.7 | Peak data rates for internal and external devices meet IEEE 1394 requirements
1394–0095.1 |  | Internal devices support the standard IEEE 1394a-2000 Amendment data rates
1394–0095.2 |  | External devices support IEEE 1394a-2000 data transfer rates
1394–0096 | 8.9 | IEEE 1394 Plug and Play devices demonstrate interoperability with other devices
1394–0097 | 8.12 | IEEE 1394 devices that initiate peer-to-peer communications provide a remote control interface
1394–0098 | 8.13 | IEEE 1394 CSR provides unique device identification
1394–0099 | 8.14 | IEEE 1394 device CSR space implements IEEE 1212-2000 format
1394–0100 | 8.18 | IEEE 1394 CSR includes a unit directory for each independent device function
1394–0101 | 8.21 | Vendor and model leafs support textual descriptor leaf format
1394–0102 | 8.36 | Power Manager notified of device power state changes
1394–0103 | 8.38 | Devices and controllers comply with all components of the 1394 Trade Association Power Specification
SCSI–0104 |  | SCSI controller complies with SPI-3
SCSI–0105 | 11.1 | PCI-based SCSI host controller supports bus mastering and virtual DMA services
SCSI–0106 | 11.2 | Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions
SCSI–0108 | 11.5 | Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators
SCSI–0109 | 11.6 | Differential devices support DIFFSENS as defined in the SPI-3 Standard
SCSI–0110 | 11.7 | Automatic termination circuit and SCSI terminators meet SPI-3 standard
SCSI–0111 | 11.8 | Terminator power is supplied to the SCSI bus with overcurrent protection
SCSI–0111.1 | 11.8.1 | Host adapter supplies terminator power
SCSI–0111.2 | 11.8.2 | The circuit that supplies TERMPWR has built-in overcurrent protection.
SCSI–0113 | 11.18 | SCAM support is disabled by default
SCSI–0114 | 11.20 | SCSI controllers provide multi-initiator support
ATA–0115 | 10.1 | ATA/ATAPI controllers comply with ATA/ATAPI-5 standards
ATA–0116 | 10.2 | Bootable ATA controller supports El Torito No Emulation mode
ATA–0117 | 10.3 | ATA controller supports Int 13h Extensions and Logical Block Addressing
ATA–0118 | 10.4 | If implemented, dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels
ATA–0119 | 10.7 | Controller supports Ultra DMA (ATA/33)
ATA–0120 | 10.8 | Controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors
ATA–0121 | 10.17 | ATA channel complies with device class power management reference specification
ATA–0122 |  | Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA
PCI–0123 | 9.1 | All PCI components comply with PCI 2.2
PCI–0057 |  | 66-MHz and 64-bit PCI buses comply with PCI 2.2 requirements
PCI–0124 | 9.3 | PCI-to-PCI bridges comply with the PCI-to-PCI bridge specification
PCI–0125 | 9.9 | All PCI devices complete memory write transaction (as a target) within specified times
PCI–0126 | 9.11 | PCI device IDs include Subsystem IDs
PCI–0127 | 9.13 | PCI interrupt routing is supported using ACPI
PCI–0130 | 9.17 | All PCI components comply with PCI Bus Power Management Interface specification
PCI–0130.1 | 9.17 | All components correctly implement configuration space registers used for power management.
PCI–0130.2 | 9.17 (PC99A)* | PCI add-on cards using 3.3Vaux operate correctly
PCI–0131 | 9.18 | System provides support for 3.3Vaux
PCI–0132 | 9.20 | PCI-based modem and network adapters support wakeup
BTH–0396 |  | All Bluetooth Host controllers meet current Bluetooth specifications
BTH–0397 |  | All Bluetooth Host controllers provide Plug and Play and revision information
BTH–0398 |  | Peripherals equipped with Bluetooth wireless technology provide Plug and Play information
BTH–0399 |  | Bluetooth peripherals support Windows class driver requirements
INPT–0133 |  | All non-integrated USB human input devices meet USB HID specifications
INPT–0134 | 13.53 | All PC 2001 input devices support Microsoft DirectInput and work simultaneously
INPT–0135 | 13.7 | Devices use USB or external bus connections rather than legacy serial or parallel ports
INPT–0136 | 13.9 | Serial port adapter meets device class specifications for its bus
INPT–0137 | 13.10 | If implemented, legacy serial port is implemented as 16550A UART or equivalent and supports 115.2K baud
INPT–0138 | 13.13 | Parallel port meets device class specifications for its bus
INPT–0139 | 13.14 | If a legacy parallel port is implemented, flexible resource configuration is supported for each parallel port
INPT–0140 | 13.20 | Daisy-chained legacy parallel port device is Plug and Play capable
INPT–0141 | 13.21 | Pointing-device connection meets requirements for its bus class
INPT–0142 | 13.23 | Keyboard connection meets requirements for its bus class
INPT–0143 | 13.24 | No interference occurs between multiple keyboards
INPT–0144 | 13.25 | If implemented, Windows and Application logo keys meet Microsoft requirements
INPT–0145 |  | If implemented, Internet browser and multimedia keys use Microsoft APIs
INPT–0146 | 13.27 | IR device uses NDIS 5.0 miniport driver
INPT–0147 | 13.28 | IR device meets IrDA specifications
INPT–0148 | 13.32 | System supports standard input speeds of 4 Mb/s
INPT–0149 | 13.33 | System provides a separate, physically isolated transceiver for each IR protocol supported
INPT–0150 | 13.30 | If a legacy IR port is implemented, flexible resource configuration is supported for each parallel port
IMAG–0151 | 22.26 | Digital still image device with an IR interface uses the Windows Sockets interface
MOBL–0152 | 6.10 | If implemented in a mobile PC, IR devices support power management
SMRT–0153 | 13.38 | Smart card reader complies with ISO/IEC 7816
SMRT–0154 | 13.39 | Smart card reader supports ISO 7816-3 T=0 and T=1 protocols
SMRT–0156 | 13.40 | Smart card reader supports 258-byte packets in T=0 and 259-byte packets in T=1
SMRT–0155 | 13.41 | Smart card reader supports inverse-convention smart cards
SMRT–0157 | 13.42 | Smart card reader supports a smart card insertion/removal monitor
SMRT–0158 | 13.43 | Smart card reader supports negotiable and specific modes
SMRT–0159 | 13.44 | Smart card reader supports 3.5795 MHz minimum clock frequency
SMRT–0161 | 13.46 | Smart card reader supports the Power Down command
SMRT–0162 |  | If input device implements a PIN data-entry keyboard, it must comply with ISO 13491-1
GRPH–0163 | 14.1 | Primary graphics adapter uses AGP or another high-speed connection
GRPH–0164 | 14.2 | System provides hardware-accelerated 3-D graphics
GRPH–0165 |  | If Digital Video Interface is implemented, it conforms to DVI specification
GRPH–0166 | 14.4 | Primary graphics adapter works normally with default VGA mode driver
GRPH–0167 | 14.5 | Adapter and driver support multiple adapters and multiple monitors
GRPH–0168 | 14.8 | Screen resolution and graphics memory capacity meet PC 2001 minimum requirements
GRPH–0169 | 14.9 | Adapter meets industry specifications for external display interface
GRPH–0170 | 14.10 | All supported color depths are enumerated
GRPH–0171 | 14.11 | Graphics operations use relocatable registers only
GRPH–0178 | 14.12 | Adapter supports adjustable gamma correction
GRPH–0179 | 14.13 | Adapter for external display supports Plug and Play monitor detection
GRPH–0180 | 14.20 | Extended resources can be dynamically relocated after system boot
GRPH–0181 | 14.21 | VGA resources can be disabled by software
GRPH–0182 | 14.22 | Frame buffer can be accessed asynchronously by the CPU and graphics accelerator
GRPH–0183 | 14.24 | Hardware supports transparent blter
GRPH–0184 | 14.25 | Hardware provides support to prevent tearing
GRPH–0185 | 14.27 | Hardware supports RGB rasterization
GRPH–0185.1 | 14.27.2 | Textures
GRPH–0185.2 | 14.27.3 | Alpha blending for 3-D graphics
GRPH–0185.3 | 14.27.4 | Lighting and fogging
GRPH–0186 | 14.29 | Hardware supports multitexturing
GRPH–0187 | 14.30 | Hardware supports texture formats
GRPH–0188 | 14.31 | Hardware complies with texture size limitations
GRPH–0189 | 14.33 | Hardware supports Z comparison modes and Direct3D-compatible formats
GRPH–0190 | 14.37 | If TV out is implemented, adapter supports overscan/underscan scaling
GRPH–0191 | 14.42 | If TV out is implemented, software supports positioning
GRPH–0192 | 14.38 | If TV out is implemented, adapter supports flicker filter
GRPH–0193 | 14.40 | If TV out is implemented, adapter supports composite video or S-video connectors
GRPH–0194 | 14.41 | If TV out is implemented, adapter also supports DVI or VGA and television output
GRPH–0195 | 14.45 | Display devices do not use VGA BIOS POST to populate PCI SID
GRPH–0196 | 14.46 | System supports conflict resolution, VGA compatibility, and extended registers
GRPH–0197 | 14.47 | Chips support linear packed-pixel frame buffer, relocatable above 16 MB
GRPH–0198 | 14.48 | Option ROM supports DDC2B
GRPH–0199 | 14.49 | Onboard graphics device can be used as a system boot device
GRPH–0200 | 14.50 | System BIOS supports large frame buffers for graphics adapters
GRPH–0201 | 14.52 | Graphics device supports IRQ and correctly populates PCI BARs
GRPH–0202 | 14.53 | System-board graphics device is not hidden from Plug and Play enumeration
GPPH–0203 | 14.54 | Graphics adapter complies with device class power management reference specification
GRPH–0204 | 14.55 | Graphics adapter complies with VBE/Core 2.0 extensions for power management
GRPH–0205 | 14.57 | Driver does not bypass any Microsoft-provided system components
GRPH–0206 | 14.59 | Driver supports dynamic color depth and resolution change
GRPH–0207 | 14.14 | If support for TV or DVD-Video playback is implemented, hardware supports video overlay surface with scaling
GRPH–0207.1 | 14.14.1 | Size
GRPH–0207.2 | 14.14.2 | Screen resolutions
GRPH–0207.3 | 14.14.3 | Color formats
GRPH–0207.4 | 14.14.4 | Scaling
GRPH–0208 |  | If support for TV or DVD-Video playback is implemented, colorspace conversion can be configured for different color primary standards
GRPH–0395 | 14.15 | Hardware supports color keying for video
GRPH–0393 | 6.18 | Mobile system meets mobile PC 2001 basic graphics requirements
GRPH–0393.1 |  | Mobile system supports display resolution of at least 640 × 480 with 256 colors
GRPH–0393.2 | 6.23 | Mobile PC system uses PCI or better interconnect
GRPH–0393.3 | 6.19 | Optional 3-D capabilities meet minimum requirements
GRPH–0393.4 | 6.18 | Mobile PC resolution requirements
GRPH–0393.5 | 6.18 | Mobile PC refresh frequency requirements
GRPH–0393.6 | 6.21 | Mobile PC requirements for Plug and Play support for external displays
GRPH–0393.7 | 6.20 | Mobile PC multiple-monitor requirements
GRPH–0393.8 | 14.49 | Mobile BIOS setup utility can force use of system-board graphics
GRPH–0394 |  | All mobile systems meet basic interoperability requirements
VID–0209 | 15.1 | System supports basic video capabilities
VID–0210 | 15.17 | Video input, capture, and broadcast device support is based on DirectX foundation class and WDM Stream class or AV Stream class
VID–0211 | 15.48 | All video implementations use DirectShow for video routing and processing
VID–0212 | 15.51 | Dependent video device is not independently enumerated
VID–0213 |  | If non-Microsoft provided DirectShow filters replace any filters included with the operating system, replacements provide a functional and qualitative superset of the replaced modules
VID–0215 |  | All video implementations meet basic video quality requirements
VID–0215.1 |  | TV-style video source frame and field rates must be preserved to memory and to the display
VID–0215.2 |  | TV-style video source resolution must be preserved to memory and to the display
VID–0215.3 |  | TV-style video source quality must be preserved to memory and display
VID–0215.4 |  | TV-style video source color information must be preserved to memory and to the display
VID–0215.5 |  | TV-style video source video aspect ratios are preserved and displayed correctly
VID–0215.6 |  | TV-style MPEG-2 video stream playback consumes no more than an additional 45 percent of CPU measured during any given minute
VID–0215.7 |  | TV-style MPEG-2 video stream playback consumes no more than an additional 45 percent of memory, PCI, or AGP bandwidth during any given minute
VID–0215.8 |  | TV-style video stream playback is audio-video synchronized to within 75 ms
VID–0215.9 |  | Video is made available through input or transform filters in the YUY2 color format while maintaining all other baseline video requirements
VID–0215.10 |  | Displayed video that enters the system interlaced but carrying a tag that identifies how the video fields were derived from a progressive source will be deinterlaced using the weave method
VID–0215.11 |  | Displayed video that enters the system interlaced but carries a tag identifying the video source as 24 fps film will be (in combination with weave deinterlacing) played back using a suitable frame rate increasing process such as 3:2 pulldown or better
VID–0215.12 |  | Displayed video that enters the system interlaced and carries either no identifying tag or is tagged as interlaced material should be deinterlaced by the graphics subsystem using the bob method or a method superior to the bob method
VID–0215.13 |  | When video is displayed on a monitor that is refreshed at a different rate than the field rates and frame rates of the video stream, a consistent frame repeat pattern must be implemented that in itself causes no frames to be dropped
VID–0216 | 15.14 | If implemented, all MPEG-2 decoders can accept an MPEG-2 elementary stream
VID–0217 | 15.15 | If implemented, all MPEG transport stream information is available to the central host processor
VID–0340 |  | If implemented, MPEG decoders with motion compensation or Inverse DCT hardware acceleration use the Microsoft-provided DirectX VA API
VID–0218 | 15.24 | If DVD-Video playback is implemented, DVD decoder driver correctly handles media types, time discontinuity, and decode-rate adjustment
VID–0219 | 15.25 | If DVD-Video playback is implemented, DVD decoder supports subpicture compositing and closed captioning
VID–0220 | 15.26 | If DVD-Video playback is implemented, subpicture decoder correctly handles subpicture properties and other functions
VID–0221 | 15.27 | If DVD-Video playback is implemented, system supports seamless DVD-Video 1.0 navigation
VID–0222 |  | If DVD-Video playback is implemented, DVD-Video player provides seamless DVD navigation
VID–0223 | 15.28 | If DVD-Video playback is implemented, All DVD-Video decoders must support Line21 closed-caption data
VID–0224 | 15.32 | If implemented, video input or capture device provides raw sampled VBI data to the host
VID–0225 | 15.37 | If implemented, VBI capture oversamples VBI data exactly 4.7 or 5 times
VID–0226 | 15.39 | If implemented, digital broadcast module can receive all streams contained in the particular transport stream
VID–0227 | 15.40 | If implemented, digital broadcast module can receive full bandwidth from each frequency
VID–0228 | 15.41 | If implemented, digital broadcast module can receive a minimum of 32 simultaneous elementary streams
VID–0229 | 15.47 | If implemented, ATSC DTV tuner/demodulator complies with A/53
MOBL–0231 | 6.22 | Mobile system meets mobile PC 2001 basic video requirements
MON–0232 | 16.1 | Color monitor is E-DDC–compliant with unique EDID identifier
MON–0233 | 16.12 | Monitor supports EDID 1.3 data structure
MON–0234 |  | If implemented, LCD monitor or built-in LCD display contains display characterization data
MON–0235 | 16.2 | Monitors support sRGB output or an ICC profile is provided
MON–0236 |  | USB functionality does not interfere with monitor INF file
MON–0237 | 16.5 | Monitor meets minimum graphics resolution, based on monitor size
MON–0238 | 16.7 | CRT-based monitor synchronizes to a new format in less than three seconds
MON–0239 | 16.12 | External monitor meets E-DDC and E-EDID standards
MON–0240 | 16.6 | CRT-based monitor supports ergonomic timing standards
MON–0241 |  | Digital display interface is DVI compliant
MON–0242 |  | Digital monitor supports hot-plug detection
MON–0243 | 16.10 | Digital monitor supports VESA VGA Text Mode 3 timings, 640 × 480 and 640 × 400
MON–0244 | 16.13 | Analog monitor complies with device-class power management reference specification
AUD–0322 | 17.3 | Audio device does not use legacy hardware interfaces for MS-DOS–based applications
AUD–0323 |  | PC 2001 audio subsystem is digital ready
AUD–0324 | 17.5 | Audio subsystem supports basic data formats
AUD–0325 | 17.6 | Audio subsystem supports full duplex operation
AUD–0325.1 | 17.6.1 | Full duplex operation is supported for all sampling rates supported by the hardware
AUD–0325.2 | 17.6.2 | Independent selection of input and output sample rates
AUD–0325.3 | 17.6.3 | Sample rates are time-synchronized
AUD–0326 | 17.8 | Audio driver reports sample position for stream synchronization
AUD–0337 | 17.31 | Audio meets PC 2001 requirements for WDM driver support
AUD–0327 |  | If implemented, audio system provides 2-D and 3-D hardware acceleration according to PC 2001 requirements
AUD–0328 | 17.12 | If implemented, audio system provides DLS acceleration according to PC 2001 requirements
AUD–0329 | 17.4 | Audio meets PC 2001 minimum performance requirements
AUD–0330 | 17.13 | Audio subsystem supports AEC reference inputs
AUD–0331 | 17.7 | If implemented, analog microphone input meets PC 2001 jack and circuit requirements
AUD–0332 | 17.11 | If implemented, close-speaking headset microphone meets PC 2001 performance requirements
AUD–0333 | 17.21 | PCI device supports initiator, target, and block transfer
AUD–0334 | 17.22 | PCI device supports efficient audio buffer management
AUD–0335 | 17.25 | USB audio meets USB specifications
AUD–0336 | 17.29 | Audio device complies with device class power management reference specification
AUD–0338 | 6.12 | Audio-enabled mobile PC meets mobile PC 2001 audio performance requirements
AUD–0339 | 6.37 | Docked mobile meets PC 2001 speaker selection requirements
STOR–0341 | 18.1 | Storage components and optical devices support bus master capabilities
STOR–0342 | 18.2 | Removable media devices support media status notification
STOR–0343 | 18.7 | USB storage devices comply with the USB mass storage class specification
SCSI–0109 | 11.6 | Differential devices support DIFFSENS as defined in SPI-3 standard
STOR–0345 | 11.12 | External devices use automatic termination or an accessible termination switch
STOR–0346 | 11.22 | Devices supports the STOP/START UNIT command as defined in the SBC standard
STOR–0347 | 10.9 | Peripherals comply with ATA/ATAPI-5
STOR–0348 | 10.12 | ATAPI devices support DEVICE RESET command
STOR–0349 | 10.18 | ATA device supports ATA STANDBY command
STOR–0350 | 18.6 | ATA devices support Ultra DMA
STOR–0352 | 18.17 | CD or DVD drive is CD-Enhanced compatible
STOR–0353 | 18.18 | CD or DVD drive supports specified logical and physical CD formats
STOR–0354 | 18.19 | CD or DVD drive complies with MMC-2
STOR–0355 | 18.20 | CD drive supports multisession and compatibility forms of the READ_TOC command
STOR–0356 | 18.21 | CD or DVD changer complies with MMC-2
STOR–0357 | 18.22 | CD or DVD device supports digital audio extraction with sector accurate reads
STOR–0360 | 18.25 | DVD device provides 2 MB per second minimum transfer rate or better performance anywhere on the disc
STOR–0361 | 18.30 | DVD drive supports defect management
STOR–0362 | 18.16 | CD device provides 8x minimum transfer rate or better performance
STOR–0363 | 18.24 | Block rewriteable optical ATAPI device complies with INF-8070i, version 1.2
STOR–0364 | 18.37 | Device and controller comply with Storage Device Class Power Management Reference Specification
STOR–0365 | 18.42 | Device driver for partitioned media supports all Windows Me and Windows 2000 partition types
MOD–0366 | 19.41 | Modem driver supports Unimodem
MOD–0367 | 19.2 | Modem meets PC 2001 controller requirements
MOD–0368 | 19.3 | Modem supports V.250 AT command set
MOD–0369 | 19.4 | Data modem meets PC 2001 protocol requirements
MOD–0370 | 19.7 | Modem supports call control signaling, controlled using V.251 modem commands
MOD–0371 | 19.8 | FAX modem supports 14.4 Kbps (V.17) with Class 1 command set
MOD–0372 | 19.9 | If delayed and blacklisted number tables are implemented, modem generates appropriate error messages
MOD–0373 | 19.10 | If TDD support is implemented, modem complies with TDD, meeting V.18-1996 with V.250 AT commands
MOD–0374 | 19.11 | If voice modem is implemented, it supports ITU V.253 (AT+V)
MOD–0375 | 19.12 | If implemented, V.253 modem supports duplex audio (+VTR)
MOD–0376 | 19.13 | If Caller ID detection is implemented, modem supports Caller ID Reporting using +VCID and +VRID commands
MOD–0377 | 19.23 | Modem can connect, stay connected, and successfully transfer data simultaneously
MOD–0378 | 19.24 | Modem reliably connects numerous times on good telephone channels
MOD–0379 | 19.25 | Modem pair functions concurrently with other applications
MOD–0380 | 19.36 | All external modems support USB specifications
MOD–0381 | 19.38 | Modem complies with device class power management reference specification
MOD–0382 | 19.39 | Modem supports wakeup events
MOD–0383 | 19.26 | Driver-based modem uses a WDM-based driver solution
MOD–0384 | 19.18 | ISDN modem supports required command set
MOD–0385 | 19.20 | ISDN modem supports asynchronous-to-synchronous conversion and RFC 1662
MOD–0386 | 19.15 | If wireless support is implemented, Mobile PC modem supports +WS46 command
MOD–0387 | 19.16 | If digital cellular control is implemented, Mobile PC modem supports appropriate +C digital cellular standards
MOD–0388 |  | If short messaging services support is implemented, the modem supports appropriate +C SMS control commands
MOD–0389 |  | System with telephony applications uses a common set of audio I/O devices for system audio and telephony applications
MOD–0390 |  | Telephony applications provided with a PC 2001 system meet industry telephony performance requirements
NET–0245 | 20.7 | Network adapter uses NDIS 5.0 miniport driver
NET–0246 | 20.10 | Adapter automatically senses presence of functional network connection
NET–0247 | 20.11 | Adapter automatically senses transceiver type
NET–0248 | 20.12 | Adapter can transmit packets from buffers aligned on any boundary
NET–0249 | 20.13 | Adapter communicates with driver across any bridge
NET–0250 | 20.50 | Networking media supports IP
NET–0251 | 20.17 | PCI-based network adapters are bus masters
NET–0252 | 20.8 | NDIS 5.0 miniport driver is deserialized
NET–0253 | 20.9 | Full-duplex adapter automatically detects and switches to full duplex mode
NET–0254 | 20.14 | Adapter supports filtering for at least 16 multicast addresses
NET–0255 | 20.15 | Adapter and driver support promiscuous mode
NET–0256 | 20.16 | Adapter can be used as a boot device
NET–0257 | 20.20 | Network adapter and driver supports priority for IEEE 802-style networks
NET–0258 | 20.21 | Internal ISDN device meets PC 2001 network adapter requirements
NET–0259 | 20.22 | Internal ISDN device supports synchronous HDLC framing
NET–0260 | 20.23 | NDIS interface and driver support raw, unframed synchronous B channel I/O
NET–0261 | 20.24 | ISDN driver supports unattended installation, with limitations
NET–0262 | 20.26 | ISDN device includes software-selectable terminating resistors
NET–0263 | 20.28 | Integrated cable modem meets PC 2001 network adapter requirements
NET–0264 | 20.29 | Integrated cable modem exposes an ATM or Ethernet interface
NET–0265 | 20.30 | ATM adapter meets PC 2001 network adapter requirements
NET–0266 | 20.31 | ATM adapter supports a minimum number of simultaneous connections
NET–0267 | 20.33 | ATM adapter supports UBR service type
NET–0268 | 20.34 | ATM adapter supports a minimum number of simultaneously active VBR or CBR connections
NET–0269 | 20.35 | ATM adapter supports traffic shaping
NET–0270 | 20.36 | ATM adapter enforces PCR on UBR virtual circuits
NET–0271 | 20.37 | ATM adapter and driver support dynamic link speed configuration
NET–0272 | 20.38 | ATM adapter that supports OAM responds to F4 and F5 loopback cells
NET–0273 | 20.41 | Integrated ADSL modem meets PC 2001 network adapter requirements
NET–0274 |  | DSL modem supports G.994.1
NET–0275 |  | CAP/QAM ADSL modem supports T1 TR-59
NET–0276 | 20.43 | DMT ADSL modem supports G.992.2
NET–0278 |  | Wireless networking media adapters support wireless extensions to NDIS
NET–0279 |  | IEEE 802.11 wireless networking adapters support industry specifications
NET–0280 | 20.45 | Infrared device meets PC 2001 network adapter requirements
NET–0281 | 20.46 | Infrared device supports both FIR and SIR
NET–0282 | 20.47 | IrDA hardware supports unattended driver installation
NET–0283 | 20.48 | If implemented, home networking adapter meets PC 2001 network adapter requirements
NET–0284 |  | Network adapter that supports HomeRF complies with SWAP specification
NET–0285 |  | If implemented, network adapter that supports HomePNA complies with 1.0 specification.
NET–0286 | 20.53 | Plug and Play capabilities support multiple adapters
NET–0287 | 20.54 | All resource settings are reported in the user interface
NET–0288 |  | External networking devices support standard control interfaces
NET–0289 | 20.55 | Adapter complies with network power management specification
NET–0290 | 20.56 | Network device supports wakeup events
NET–0291 | 20.58 | Driver works correctly with Microsoft network clients and protocols
NET–0292 | 20.59 | NDIS miniport driver makes only NDIS library calls or WDM system calls
NET–0293 | 20.60 | NDIS 5.0 driver uses Windows 2000 INF file format
PRNT–0294 |  | Device uses USB, IEEE 1394, or network interface port connection
PRNT–0295 | 21.8 | Network printer supports standard port monitor
PRNT–0296 |  | Device with IEEE 1284.4 capabilities complies with specification
PRNT–0297 |  | MFP devices correctly implement multifunction support
PRNT–0298 | 21.11 | Printer INF file and installation meet PC 2001 requirements
PRNT–0299 | 21.12 | Driver correctly reports device capabilities
PRNT–0300 | 21.14 | Driver supports sRGB output or an ICC profile is provided
PRNT–0301 |  | Color printer complies with Windows Color Quality Specifications
PRNT–0302 | 21.15 | Port monitor software meets DDK requirements
PRNT–0303 | 21.16 | Driver supports point-and-print network installation
PRNT–0304 | 21.17 | Device is available immediately following installation
PRNT–0305 | 21.18 | Device supports accurate printable regions
PRNT–0306 | 21.19 | Driver supports required DDIs
PRNT–0307 |  | Printer driver does not run in kernel mode
PRNT–0308 |  | Printer device and driver support Default Device-class Power Management Specification
IMAG–0309 | 22.1 | Digital still camera uses PC 2001 compatible port connection with USB or IEEE 1394 connection
IMAG–0310 | 22.3 | Driver supports sRGB output or an ICC profile is provided
IMAG–0311 | 22.9 | USB device meets USB imaging device class specifications
IMAG–0312 | 22.12 | Still image devices meet minimum throughput requirements
IMAG–0313 | 22.14 | Digital camera uses PC-compatible file system for removable storage
IMAG–0314 | 22.15 | Digital camera stores images in JPEG-compressed file format
IMAG–0315 |  | Still image devices deliver accurate image information
IMAG–0316 |  | USB camera firmware supports PIMA 15740 protocol
IMAG–0317 | 22.23 | Driver support implements the WIA driver architecture
IMAG–0318 | 15.52 | Digital still cameras that stream video require WDM Stream class drivers
IMAG–0319 | 22.25 | If TWAIN datasources are provided, device driver supports TWAIN 1.7
IMAG–0321 | 22.27 | Scanners with an IEEE 1394 interface uses SBP2Port

* PC 99 Addendum


Appendix D Master Reference List

The following represents a consolidation of the references, services, and tools available to help build hardware that is optimized to work with Windows operating systems presented at the end of each chapter of this design guide.

1394 Open Host Controller Interface Specification, Release 1.1

http://www.microsoft.com/hwdev/1394/
http://developer.intel.com/technology/1394/download/ohci_11.htm

1394 Trade Association Power Specification Part 1: Cable Power Distribution
1394 Trade Association Power Specification, Part 3: Power State Management

ftp://ftp.p1394pm.org/pub/p1394pm/

1394 Trade Association:

E-mail: 1394-sig@1394ta.org
http://www.1394ta.org

Accelerated Graphics Port Interface Specification, Revision 2.0

http://developer.intel.com

"ACPI Docking for Windows 2000"

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

Advanced Configuration and Power Interface Specification, Revision 1.0b (ACPI 1.0b)

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

AGP Pro Specification, Revision 1.1a

http://www.agpforum.org/downloads/apro_r10.pdf

An Interoperable End-to-end Broadband Service Architecture over ADSL Systems (Version 3.0)

http://www.microsoft.com/hwdev/network/dsl/

Application Specification for Microsoft Windows 2000, for desktop applications, Version 1.0

http://msdn.microsoft.com/certification/appspec.asp

AT Attachment with Packet Interface – 5 (ATA/ATAPI-5)

ftp://fission.dt.wdc.com/pub/standards/x3t13/project/d1321r3.pdf

ATA and ATAPI draft standards and other working documents

http://www.t13.org
Global Engineering Documents
http://global.ihs.com/

ATAPI Removable Media Device BIOS Specification, Version 1.0

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

ATAPI Removal Rewriteable Media Devices (INF-8070i)

ftp://fission.dt.wdc.com/pub/standards/SFF/specs/INF-8070.PDF

ATM User Network Interface (UNI) Specification Version 3.1, 1/e

Prentice Hall; 1995
ISBN 0-13-393828-X
http://www.atmforum.com/

ATSC Digital Television Standard and Amendment No.1 (A/53)

National Association of Broadcasters
(800) 368-5644
Society of Motion Picture and Television Engineers, (914) 761-1100
E-mail: mktg@smpte.org
http://www.atsc.org/Standards/stan_rps.html

Audio Codec ’97, Revision 2.1

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

Audio Device Class Power Management Reference Specification, Version 1.0

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

Audio/Modem Riser Card Specification, Revision 1.01

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

BIOS Boot Specification, Version 1.01

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

Bluetooth Special Interest Group (SIG): See Specification of the Bluetooth System

Boot Integrity Services Application Programming Interface, Version 1.0

http://developer.intel.com/ial/wfm/wfmspecs.htm

Color Management and Windows Operating Systems Web page

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

Common Application Environment (CAE) Specification

http://www.opengroup.org/onlinepubs/9629399/toc.htm

Communications Device Class Power Management Reference Specification, Version 1.0

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

Computer Display Monitor Timing Specifications, Version 1, Rev. 0.8

http://www.vesa.org/standards.html

Data-Over-Cable Service Interface Specifications (DOCSIS)

http://www.cablemodem.com/

Debug Port Specification

http://www.microsoft.com/hwdev/NewPC/debugspec.htm

Default Device Class Power Management Reference Specification, Version 1.0

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

Device Bay Specification, Version 1.0

http://www.device-bay.org

Device class power management reference specifications

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

Digital Visual Interface (DVI), Revision 1.0

http://www.ddwg.org

Display Device Class Power Management Reference Specification, Version 1.0b

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

Display Technology Web page

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

DOCSIS: See Data-Over-Cable Service Interface Specifications

DVB/DAVIC (Digital Video Broadcasting/Digital Audio Visual Council)

http://www.dvb.org
http://www.davic.org

"DVD and Microsoft Operating Systems"

http://www.microsoft.com/hwdev/devdes/dvdwp.htm

DVD Specification, Version 1.0

Toshiba Corporation
http://www.toshiba.com

DVD Specifications for Rewritable Disc, Part 1: Physical Specifications

Toshiba Corporation
http://www.toshiba.com

Easy PC Initiative and legacy-free design

http://developer.intel.com/technology/easeofuse/
http://www.microsoft.com/hwdev/newpc/

ECMA Standards: ECMA-267 (DVD-ROM), ECMA-272, 273 (DVD-RAM) and ECMA-274 (+RW)

http://www.ecma.ch/

EIA standards

Global Engineering Documents
http://global.ihs.com/

"El Torito" Bootable CD-ROM Format Specification, Version 1.0

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

Enhanced BIOS Services for Disk Drives [T13-1226DT], Revision 7

http://global.ihs.com

Enhanced Host Controller Interface Specification for Universal Serial Bus 2.0

To be published on http://www.usb.org/ when available

European Telecommunications Standards Institute (ETSI) or Global System for Mobile (GSM) standards

Phone: +33-92 94 42 00
FAX: +33-93 65 47 16
E-mail: secretariat@etsi.fr
http://www.etsi.org/

Global Engineering Documents

http://global.ihs.com

Handshake procedures for digital subscriber line (DSL) transceivers

http://www.itu.int/

"HID Support Routines for MiniDrivers"

http://www.microsoft.com/DDK/

Home Phoneline Networking Alliance Spec, Version 1.0

http://www.homepna.org

Home Radio Frequency (HomeRF) Working Group

http://www.homerf.org

Hot-Plug PCI and Windows 2000 Web page

http://www.microsoft.com/hwdev/pci/hotplugpci.htm

Icons for PCs Web page

http://www.pcdesguide.org/documents/icons.htm

IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB

http://www.iec.ch

IEEE 802.14 Cable TV Working Group

http://www.walkingdog.com/

IEEE 1212-2000
IEEE 1394-1995 Standard for a High Performance Serial Bus
IEEE 1394a-2000 amendment to IEEE 1394-1995
IEEE P1394b

Other IEEE standards
http://standards.ieee.org/reading/ieee/std/busarch/1394-1995.pdf
http://standards.ieee.org/index.html
http://global.ihs.com

IEEE specifications

ASKIEEE
Phone: (800) 949-4333
Fax: (212) 310-4091
E-mail: askieee@ieee.org
http://www.ieee.org

Global Engineering Documents
Fax: (303) 397-2740
Phone: (800) 854-7179 (US)
(613) 237-4250 (Canada)
(303) 792-2181 (Outside North America)
Fax: 1 (303) 397-2740
http://global.ihs.com/

Implementing Legacy Audio Devices on the PCI Bus

http://developer.intel.com/ial/scalableplatforms/audio/doc.htm

Infrared Data Association (IrDA) documents

Infrared Data Association
PO Box 3883
Walnut Creek, CA 94598 USA
Phone: (510) 943-6546
Fax: (510) 943-5600
E-mail: info@irda.org
http://www.irda.org/standards/specifications.asp

Infrared Extensions to the NDIS Version 4.0 Functional Specification

http://www.cablemodem.com/

Instantly Available PC System Power Delivery Requirements and Recommendations

http://developer.intel.com/design/power/supply98.htm

Instantly Available Power Managed Desktop PC Design Guide

http://developer.intel.com/technology/iapc/tech.htm

Intel information for developers

http://developer.intel.com

International Color Consortium (ICC)

http://www.color.org

Interoperability Specification for ICCs and Personal Computer Systems Specification, Revision 1.0 (PC/SC Specification)

http://www.pcscworkgroup.com/

"IP Multicast over Token-Ring Local Area Networks"

RFC 1469
http://www.rfc-editor.org/rfc.html

Infrared Transfer Picture Specification (IrTran-P), Version 1.0

http://www.irda.org/standards/specifications.asp

IrDA Control Specification
IrDA Serial Infrared Data Link Standard Specifications

http://www.irda.org/standards/specifications.asp

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

ISO/IEC 7811-1:1995 Identification Cards—Recording technique—Part 1: Embossing

http://www.iso.ch/cate/d14717.html

ISO/IEC 7811-3:1995 Identification Cards—Recording technique—Part 3: Location of embossed characters on ID-1 cards

http://www.iso.ch/cate/d14721.html

ISO/IEC 7813:1995 Identification Cards—Financial transaction cards

http://www.iso.ch/cate/d14731.html

ISO/IEC 7816-1:1998 Identification cards—Integrated circuit(s) cards with contacts—Part 1: Physical characteristics

http://www.iso.ch/cate/d29257.html

ISO/IEC 7816-2:1999 Information technology—Identification cards—Integrated circuit(s) cards with contacts—Part 2: Dimensions and location of the contacts

http://www.iso.ch/cate/d26536.html

ISO/IEC 7816-3:1997 Information technology—Identification cards—Integrated circuit(s) cards with contacts—Part 3: Electronic signals and transmission protocols

http://www.iso.ch/cate/d14735.html

ISO/IEC 10373:1993 Identification cards—Test methods

http://www.iso.ch/cate/d18434.html

ISO 13491-1:1998 Banking—Secure cryptographic devices (retail)—Part 1: Concepts, requirements and evaluation methods

http://www.iso.ch/cate/d19521.html

Ordering information:
ISO Central Secretariat
Post Office Box 56
CH-1211 GENE
Switzerland
Phone: +22-749-011
Fax: +22-733-3430
E-mail: sales@iso.ch
Catalog of available standards at:
http://www.iso.ch/cate/cat.html

ITU (International Telecommunication Union) communications standards

E-mail: sales@itu.ch
http://www.itu.ch

"Kernel Streaming Overview"

http://www.microsoft.com/ddk/

Key Support and Keyboard Scan Codes for Windows Web page

http://www.microsoft.com/hwdev/desinit/scancode.htm

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/LegacyPnP/

Low Pin Count (LPC) Interface Specification

http://developer.intel.com/design/chipsets/industry/lpc.htm

Media Status Notification Support Specification, Version 1.03

http://www.microsoft.com/hwdev/respec/storspec.htm

Microsoft DirectInput DDK provided with the Windows 98 DDK

http://www.microsoft.com/ddk/

Microsoft DirectShow

http://msdn.microsoft.com/directx/

Microsoft information for hardware manufacturers

http://www.microsoft.com/hwdev/
E-mail: ihv@microsoft.com

Microsoft Windows Hardware Quality Laboratory testing tools

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

Microsoft Windows Logo Program for Hardware Web page

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

Modem Technology Web page

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

MSDN Professional membership

Fax: (425) 936-7329, Attn: Developer Network
E-mail: msdn@microsoft.com
http://msdn.microsoft.com/subscriptions/

Multifunction Print Device Design Guidelines

http://www.microsoft.com/hwdev/mf/mfp.htm

Multimedia Commands – 2 (MMC-2)
ANSI NCITS 333-2000

ftp://ftp.t10.org/t10/drafts/mmc2/mmc2r11a.pdf

MultiRead Specifications for CD-ROM, CD-R, CD-R/RW, & DVD-ROM Devices, Revision 1.11

http://www.osta.org/html/mrspec.html

Multisession Compact Disc Specification Enhanced Music CD Specification, Version 1.0

Philips Consumer Electronics B.V.
Coordination Office Optical–Magnetic Media Systems
Building SWA-109, PO Box 80002
5600 JB Eindhoven, The Netherlands
Fax: (31) (40) 732113

Network Device Class Power Management Reference Specification, Version 1.0a

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

New Key Support for Windows Web page

http://www.pcdesguide.org/documents/keycode.htm

OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

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

Specification drafts:
http://www.microsoft.com/hwdev/1394/

OnNow and Power Management Web page

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

PAE Server Design Web page

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

PC Card Standard, Release 7

http://www.pcmcia.org/bookstore.htm

PC Design Guides Web page

http://www.pcdesguide.org

PC Card and CardBus Guidelines, Version 1.1

http://www.pcdesguide.org/library/pccard.htm

PCI Bus Power Management Interface Specification, Revision 1.1
PCI Bus Power Management Interface Specification, Revision 1.0

PCI SIG
Phone: (800) 433-5177
http://www.pcisig.com/developers/specification/

"PCI Device Subsystem IDs and Windows"

http://www.microsoft.com/hwdev/devdes/pciids.htm

PCI Hot-Plug Specification, Revision 1.0

http://www.pcisig.com/developers/specification/

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/developers/docs/

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/developers/specification/

PCI to PCI Bridge Architecture Specification Rev. 1.1

PCI SIG
Phone: (800) 433-5177
http://www.pcisig.com/developers/specification/

PCI-X Specification, Revision 1.0 (PCI-X 1.0)

http://www.pcisig.com/developers/specification/

Personal Computer Audio Quality Measurements

by Dr. Steven Harris and Cliff Sanchez, Crystal Semiconductor
http://www.cirrus.com/products/papers/meas/meas.html

PIMA 15740:2000 Photography – Electronic still picture imaging – Picture Transfer Protocol (PTP) for Digital Still Photography Devices

http://www.pima.net/standards/it10/IT10_POW.htm#15740
See also the implementation guidelines in the Windows 2000 DDK.

Plug and Play External COM Device Specification, Version 1.0
Plug and Play ISA Specification, Version 1.0a and Clarifications to the Plug and Play ISA Specification, Version 1.0a
Plug and Play Parallel Port Devices, Version 1.0b
Plug and Play Design Specification for IEEE 1394, Version 1.0c

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

Preboot Execution Environment (PXE) Specification, Version 2.1

http://developer.intel.com/ial/wfm/wfmspecs.htm

Reduced Block Commands (RBC)

ftp://ftp.t10.org/t10/drafts/rbc/rbc-r10a.pdf

RFC 1469: See "IP Multicast over Token-Ring Local Area Networks."
RFC 1179
RFC 1662
RFC 1663

http://www.rfc-editor.org/rfc.html

"SBP-2 Support and Windows 2000"

http://www.microsoft.com/hwdev/print/sbp2_w2000.htm

"Scan Codes for Keyboard Power Switches"

http://www.microsoft.com/hwdev/desinit/scancode.htm

SCSI-3 Block Commands (SBC)

ftp://ftp.t10.org/t10/drafts/sbc/sbc-r08c.pdf

SCSI-3 Parallel Interface (SPI)

ANSI X3.253-1995
http://web.ansi.org/public/std_info.html

SCSI Multimedia Commands – 2 (MMC-2)

ANSI NCITS 333-2000
ftp://ftp.t10.org/t10/drafts/mmc2/mmc2r11a.pdf

SCSI Parallel Interface – 2 (SPI-2)

ANSI X3.302-1998
http://web.ansi.org/public/std_info.html

SCSI Parallel Interface-3 (SPI-3)

ftp://ftp.t10.org/t10/drafts/spi3/spi3r14.pdf

SCSI standards and documents, other

Global Engineering Documents
Phone: (800) 854-7179 (US)
(613) 237-4250 (Canada)
(303) 792-2181 (Outside North America)
Fax: (303) 397-2740
http://global.ihs.com/

Serial Bus Protocol 2 (SBP-2)

ANSI NCITS 325-1998
http://web.ansi.org/public/std_info.html

Shared Wireless Access Protocol (SWAP) Specification, Version 1.1

http://www.homerf.org/tech/

Smart Battery Charger Specification, Revision 1.1
Smart Battery Data Specification, Revision 1.1
Smart Battery System Manager Specification, Revision 1.0

http://www.sbs-forum.org/specs/

Specification of the Bluetooth System, Volume 1: Core, v1.0 B
Specification of the Bluetooth System, Volume 2: Profiles, v1.0 B

Bluetooth Special Interest Group (SIG)
http://www.bluetooth.com

Specification ICC.1:1998-09 File Format for Color Profiles

http://www.color.org/ICC-1_1998-09.PDF

Specification of the Bluetooth System, Volume 1: Core, Version 1.0 B
Specification of the Bluetooth System, Volume 2: Profiles, Version 1.0 B

http://www.bluetooth.com

STD-201: Extensions to NDIS for Wireless WANs

http://www.pcca.org/standards/standards.htm

Storage Device Class Power Management Reference Specification, Version 1.0a

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

Storage Technology Web page

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

"Supporting Removable Devices under Windows"

http://www.microsoft.com/hwdev/busbios/rem_devs.htm

System Management BIOS Reference Specification, Version 2.3

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

System Test Implementers Forum

http://www.systemtest.org

TIA and other standards:

Global Engineering Documents
Phone: (800) 854-7179 (US)
(613) 237-4250 (Canada)
(303) 792-2181 (Outside North America)
Fax: (303) 397-2740
http://global.ihs.com/

TWAIN Specification, Version 1.7

http://www.twain.org/docs/

Unimodem Diagnostics Command Reference Specification

http://www.microsoft.com/hwdev/respec/commspec.htm

Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1

http://www2.fm.intel.com/pcd_ae/public/general/specs_ind/USB/uhci_1_1.pdf

Universal Serial Bus Class Definitions for Communication Devices, Version 1.0
Universal Serial Bus Common Class Specification, Revision 1.0
Universal Serial Bus Device Class Definition for Audio Devices, Release 1.0
Universal Serial Bus Device Class Definition for Device Bay Controllers
Universal Serial Bus Device Class Definition for Printing Devices, Version 1.1
Universal Serial Bus Mass Storage Class Specification Overview, V1.0 Revision
Universal Serial Bus PC Legacy Compatibility Specification, 0.9 Draft Revision

http://www.usb.org/developers/devclass_docs.html

Universal Serial Bus Specification, Revision 1.1
Universal Serial Bus Specification, Revision 2.0

http://www.usb.org/developers/docs.html

Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1

http://www.usb.org/developers/data/devclass/hid1_1.pdf

Update on ClearType Font Technology and LCD Displays Web page

http://www.microsoft.com/hwdev/video/clrtype.htm

USB HID Usage Tables, Version 1.1

http://www.usb.org/developers/hidpage.html

USB Imaging Class Specification
USB Monitor Control Class Specification, Revision 1.0
USB Still Image Capture Device Definition Specification

http://www.usb.org/developers/docs.html
http://www.usb.org/developers/devclass_docs.html

U.S. T1 committee Technical Report TR-59, "Single-Carrier Rate Adaptive Digital Subscriber Line (RADSL)"

http://www.t1.org/html/trs.htm

VESA BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0)

VESA Display Data Channel (DDC) Standard, Version 3

VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1

VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A

VESA Extended Display Identification Data (EDID) Standard, Version 3

VESA Generalized Timing Formula (GTF), Version 1.1

Video Electronics Standards Association (VESA)
Phone: (408) 435-0333
Fax: (408) 435-8225
http://www.vesa.org/standards.html

Videophone-ready Modem Handbook, Version 1.0

http://developer.intel.com/ial/vidred/index.htm

"WDM Kernel Streaming Architecture"

http://www.microsoft.com/hwdev/desinit/csa1.htm

Windows 95 DDK, Windows 98 DDK, Windows Me DDK, Windows 2000 DDK, DirectX DDK and SDK, and Microsoft Platform SDK, including information about WDM and NDIS

http://www.microsoft.com/ddk/
http://msdn.microsoft.com/library/default.asp

"Windows 98 MS-DOS Box Game Compatibility"

ftp://download.intel.com/ial/sm/compatibility.pdf

"Windows color quality specifications for printer OEMs"

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

Windows Driver Model (WDM) Technology Web page

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

Windows Hardware Instrumentation Implementation Guidelines, Version 1.0

White papers and guidelines for WMI

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

Windows Logo Program Requirements

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

Windows Image Acquisition Web page

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

"Windows Support for HID-based Audio Controls"

http://www.microsoft.com/hwdev/hid/audctrl.htm

Windows Update Web page

http://windowsupdate.microsoft.com

Wired for Management Baseline

Version 1.1a
Version 2.0 Release — http://developer.intel.com/ial/wfm/wfmspecs.htm


PC 2001 Glossary

Acronyms and Abbreviations

1V/Pa 1 Volt per Pascal

ABR available bit rate

AC alternating current

ACPI Advanced Configuration and Power Interface

ADC analog-to-digital converter

ADSL asymmetric digital subscriber line

AEC acoustic echo cancellation

AGP Accelerated Graphics Port

AMR audio modem riser

API application programming interface

APIC Advanced Programmable Interrupt Controller

APM Advanced Power Management

ARP address resolution protocol

ATA AT Attachment

ATAPI ATA Packet Interface

ATM Asynchronous Transfer Mode

ATSC Advanced Television Systems Committee

A/V audio/video

BAR base address register

BIOS basic I/O system

BIS Boot Integrity Services

blt block transfer

blting block transferring

bpp bits per pixel

bps bits per second

CAP Carrierless Amplitude Phase

CAPI COMMON ISDN-API

CBR constant bit rate

CDMA code division multiplexed access

CDPD cellular digital packet data

CD-R CD-Recordable

CD-RW CD-ReWritable

CE consumer electronics

CMTS cable modem termination system

CPU central processing unit

CRC cyclic redundancy check

CRT cathode ray tube

CSR control and status register

DAC Dual Address Cycle

DASD direct access storage devices

DAVIC Digital Audio Visual Council

dB decibel

dBSPL decibel Sound Pressure Level

DBC Device Bay Controller

DDC display data channel

DDC2B DDC Standard, Version 2.0, Level B

DDI device driver interface

DDK Driver Development Kit

DDMA Distributed Direct Memory Access

DIX Digital-Intel-Xerox

DLS Downloadable Sounds

DMA direct memory access

DMT discrete multitone

DOCSIS Data-Over-Cable Service Interface Specification

DRV device driver

DSL Digital Subscriber Line

DSTN Double Supertwisted Nematic

DTV digital television

DVB Digital Video Broadcast

DVD See Glossary

DVI Digital Visual Interface

EAZ EndgerateAushlZiffer

EC embedded controller-based

ECC error correction code

ECP extended capabilities port

EDID Extended Display Identification Data

E-DDC Enhanced Extended Display Data Channel

E-EDID Enhanced Extended Display Identification Data

ETSI European Telecommunications Standards Institute

FAT file allocation table

FDC floppy disk drive controller

FDD floppy disk drive

FDDI Fiber Distributed Data Interface

FET field effect transistor

FIFO first in/first out

FIR Fast IR

FM frequency modulation

fps frames per second

FS full scale

FSIV full-scale input voltage

FSOV full-scale output voltage

GART Graphics Address Remapping Table

GOP group of pictures

GSM global system for mobile communications

HCI See OpenHCI

HDC hard disk drive controller

HDD hard disk drive

HDLC High-level Data Link Control

HDSL High bit-rate Digital Subscriber Line

HID Human Interface Device

HomePNA Home Phoneline Networking Alliance

HomeRF Home Radio Frequency

HRFWG HomeRF Working Group

HVD high voltage differential

Hz Hertz ICC International Color Consortium

ICD Installable Client Driver

ICM Image Color Management

IDE Integrated Device Electronics

IEC International Electrotechnical Commission

IEEE Institute for Electrical and Electronics Engineers, Inc

IETF Internet Engineering Task Force

IFSC Information Field Size integrated circuit Card

IFSD Information Field Size Device

ILMI Interim Local Management Interface

INF information file

INI initialization file

I/O input/output

IOAPIC Input/Output (subsystem) APIC

IP Internet Protocol

IR infrared

IrDA Infrared Data Association

IRP I/O request packet

IRQ interrupt request

ISA Industry Standard Architecture

ISDN Integrated Services Digital Network

ISO International Standards Organization

ISP Internet service provider

ITU International Telecommunication Union

ITU-T International Telecommunication Union – Telecommunication Standardization Sector

KB kilobyte

Kbps kilobits per second

kHz kilohertz

LAN local area network

LAPM Link Access Protocol Modem

LBA logical block addressing

LCD liquid crystal display

LPD Line Printer Daemon

LPR Line Printer Remote

LPT line printer

LSB least significant bit

LUN logical unit number

LVD low voltage differential

MAC Media Access Control

MB megabyte

Mbps megabits per second

MCD Mini-Client Driver

MCNS Multimedia Cable Network System

MDK Modem Developers Kit

MFP multifunction printer

MHz megahertz

MIDI Musical Instrument Digital Interface

MMC-2 Multimedia Command Set 2

MPEG Moving Picture Expert Group

ms millisecond

MSB most significant bit

MSDN Microsoft Developer Network

mV millivolt

NABTS North American Basic Teletext

NDIS Network Driver Interface Specification

NMI Nonmaskable Interrupt

NTFS Windows NT file system

NTSC National Television System Committee

OAM operation and maintenance

OEM original equipment manufacturer

OOBE out-of-box experience

OpenHCI Open Host Controller Interface

PAL Phase Alternation Line

PAN personal area network

PC personal computer

PCAQM Personal Computer Audio Quality Measurements

PCI Peripheral Component Interconnect

PCIC PC Card I/O cards

PCI-X a proposed extension to PCI

PCMCIA Personal Computer Memory Card International Association

PCR peak cell rate

PES Packetized Elementary Stream

PHY Physical Layer

PIC programmable interrupt controller

PIMA Photographic and Imaging Manufacturers Association

PIN Personal Identification Number

PIO programmed I/O

PIT programmable interrupt timer

PME power management event (PME# assertion)

POST power-on self-test

POTS plain old telephone service

PPP point-to-point protocol

PSTN Public Switched Telephone Network

PTP Picture Transfer Protocol

PTT Post, Telephone, and Telegraph

PXE Preboot Execution Environment

QAM Quadrature Amplitude Modulation

QOS quality of service

RADSL rate adaptive digital subscriber line

RAID redundant array of inexpensive disks

RAM random-access memory

RAMDAC RAM digital-to-analog converter

RBC reduced block command

RF radio frequency

RFC request for comments

RGB red-green-blue

RLI remote lockout interface

RSVP Resource Reservation Setup Protocol

SBC SCSI-3 block commands

SCAM SCSI Configured AutoMagically

SCSI small computer system interface

SDID Subsystem Device ID

SDK Software Development Kit

SDP Service Discovery Protocol

SFF Small Form Factor

SID Subsystem ID

SIG Special Interest Group

SIR Serial IR

SMBIOS system management BIOS

SMBus System Management Bus

SMS short messaging services

SPI SCSI Parallel Interface

SPID service profile ID

SRC sample rate converter

sRGB standard red-green-blue

SVID Subsystem Vendor ID

SWAP Shared Wireless Access Protocol

TAPI Telephony Application Program Interface

TCP/IP Transmission Control Protocol/ Internet Protocol

TDD Telephone Device for the Deaf

TDMA time division multiplexed access

TERMPWR terminator power

THD+N total harmonic distortion

UART Universal Asynchronous Receiver/Transmitter

UBR unspecified bit rate

UDF Universal Disk Format

UID Unique ID

Unimodem universal modem driver

USB Universal Serial Bus

UUID universal unique ID

V volts

VBE VESA BIOS Extension

VBI vertical blanking interval

VBR variable bit rate

VC virtual channel

VCI virtual channel ID

VDC volts direct current

VESA Video Electronics Standards Association

VFIR Very Fast IR

VGA video graphics array

VPI virtual path ID

VRMS volts root-mean-square

VxD virtual device driver

WAN wide area network

WDM Windows Driver Model

WFM Wired for Management initiative

WHIIG Windows Hardware Instrumentation Implementation Guidelines

WHQL Windows Hardware Quality Laboratory

WIA Windows Image Acquisition

WMDM Windows Media Device Manager

WMI Windows Management Instrumentation


Glossary

A

AC-3 An audio standard developed by Dolby Laboratories for delivering 5.1 audio. This system compresses six channels of digital audio into 384 Kbps versus 4 Mb/s uncompressed.

ACPI Advanced Configuration and Power Interface. A specification that defines a new interface to the system board. This interface enables the operating system to implement operating system–directed power management and system configuration. ACPI allows system manufacturers to build systems consistent with the OnNow design initiative for instantly available PCs.

ACPI hardware Computer hardware with the features necessary to support operating system power management and with the interfaces to those features described using the Description Tables as specified in the ACPI specification.

adapter See device.

add-on devices Devices that are traditionally added to the base PC system to increase functionality, such as audio, networking, graphics, SCSI controller, and so on. Add-on devices fall into two categories: devices built onto the system board, and devices on expansion cards added to the system through a system-board connector such as PCI.

ADSL Asymmetric Digital Subscriber Line. A method for moving data over regular phone lines. An ADSL circuit is much faster than a regular phone connection, even though the wires coming into the subscriber’s premises are the same (copper) as used for regular phone service.

Advanced Power Management A legacy 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.

analog A method of signal representation by an infinitely smooth universe of numeric values. Measurements that are characterized as analog include readings of voltage and current. Compare with digital.

analog video A video signal that represents an infinite number of smooth gradations between given video levels. Compare with digital video.

API Application programming interface. A set of routines that an applications program uses to request and carry out lower-level services performed by a computer operating system.

architecture A general term referring to the structure of all or part of a computer system. Also refers to the design of system software, such as the operating system, as well as to the combination of hardware and basic software that links machines on a computer network.

ATA AT Attachment. A compatible register set, and a 40-pin connector and its associated signals. More commonly known as IDE.

ATAPI ATA Packet Interface. A hardware and software specification that documents the interface between a host computer and the CD-ROM drives using the ATA bus.

ATM Asynchronous transfer mode. A transmission protocol that segments user traffic into small, fixed-size units called cells that are transmitted to their destination, where they are reassembled into the original traffic. During transmission, cells from different users may be intermixed asynchronously to maximize utilization of network resources.

B

BIOS Basic I/O system. A set of routines that works closely with the hardware to support the transfer of information between elements of the system, such as memory, disks, and the monitor. Although critical to performance, the BIOS is usually invisible to the end user; however, programmers can access it.

C

CD-ROM Compact disc read-only memory. A 4.75-inch laser-encoded optical memory storage medium (developed by NV Philips and Sony Corporation) with the same constant linear velocity (CLV) spiral format as compact audio discs and some video discs. CD-ROMs can hold about 550 MB of data.

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.

class driver A driver that provides system-required, hardware-independent support for a given class of physical devices. Such a driver communicates with a corresponding hardware-dependent port driver, using a set of system-defined device control requests, possibly with additional driver-defined device control requests. Under WDM, the class driver creates a device object to represent each adapter registered by minidrivers. The class driver is responsible for multiprocessor and interrupt synchronization.

codec Coder-decoder. A filter that manipulates data in some form, usually by compressing or decompressing the data stream.

COM (1) Component Object Model; the core of OLE (object linking and embedding). Defines how OLE objects and their clients interact within processes or across process boundaries. (2) Legacy serial port.

configuration manager The Windows Plug and Play system component 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, real mode, and protected mode—have their own configuration managers.

control method A definition of how an ACPI-compatible operating system can perform a simple hardware task. For example, the operating system invokes control methods to read the temperature of a thermal zone. Control methods are written in an encoded language called AML (ACPI Machine Language).

CPU Central processing unit. A computational and control unit of a computer; the device that interprets and executes instructions. By definition, the CPU functions as the "brain" of the computer.


D

DDC Display data channel. The Plug and Play baseline for monitors. 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.

Device Bay An industry specification that defines a mechanism for both peripheral devices and system bays. Allows adding and upgrading PC peripheral devices without opening the chassis.

device ID A unique ASCII string for a device created by enumerators to identify a hardware device and used to cross-reference data about the device stored in the registry. Distinguishes each logical device and bus from all others on the system.

digital A method of signal representation by a set of discrete numerical values, as opposed to a continuously fluctuating current or voltage. Compare with analog.

digital video A video signal represented by computer-readable binary numbers that describe a finite set of colors and luminance levels. Compare with analog video.

DLL Dynamic link library. API routines 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 points the executable image to the DLL procedures at run time.

DMA Direct memory access. A method of transferring data between peripheral and host memory without processor intervention. 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.

docking station The base computer unit into which a user can insert a portable computer, expanding it to a desktop equivalent. A typical docking station provides drive bays, expansion slots, all the ports on an equivalent desktop computer, and AC power.

driver Kernel-mode code used either to control or emulate a hardware device.

DTV Digital television. DTV standards allow standard resolution mode—with about twice the horizontal resolution of conventional analog broadcasts—as well as HDTV mode. Video uses MPEG-2 digital compression, and audio uses AC-3 (Digital Dolby) compression.

DVD Digital video disk. Optical disk storage that encompasses audio, video, and computer data.

E

ECP Extended capabilities port. An asynchronous, 8-bit–wide parallel channel defined by IEEE 1284-1944 that provides PC-to-peripheral and peripheral-to-PC data transfers.

embedded controller The general class of microcontrollers used to support OEM-specific implementations, mainly in mobile environments. The embedded controller performs complex low-level functions through a simple interface to the host microprocessor.

embedded controller interface ACPI defines a standard hardware and software communications interface between an operating system driver and an embedded controller—for example, Smart Battery and AML code. This allows any operating system to provide a standard driver that can directly communicate with an embedded controller in the system, thus allowing other drivers to communicate with and use the resources of system embedded controllers.

expansion bus A group of control lines that provide a buffered interface to devices located either on the system board or on cards that are plugged into expansion connectors. Common expansion buses included on the system board are USB, PC Card, and PCI.

expansion card A card that connects to an expansion bus and contains one or more devices.

F

FDC Floppy disk controller. A special-purpose chip and associated circuitry that directs and controls reading from and writing to a computer’s disk drive.

FIFO First in/first out. A method for processing a queue in which items are removed in the same order in which they were added.

FS A Decibels relative to full scale, measured using "A weighting" filters.


H

HCI Host controller interface. For example, a system-level interface supporting USB.

HDC Hard disk controller. A special-purpose chip and circuitry that directs and controls reading from and writing to a computer’s disk drive.

HID specification The device class definition developed by the USB standards group for Human Interface Devices. Serves as the basis for WDM input device support, and unifies input devices by providing flexible data reporting, typeless data, and arrayed and variable input and output.

I

ID Identifier. Generally, any text string used as a label, such as the name of a procedure or a variable in a program, or the name attached to a hard drive or floppy disk.

IDE 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.

IEEE Institute of Electrical and Electronics Engineers, pronounced "I-triple-E." Founded in 1963, IEEE is an organization composed of engineers, scientists, and students. IEEE is best known for developing standards for the computer and electronics industry.

INF file Information file. A file created for a particular adapter that provides the operating system with information required to set up a device, such as a list of valid logical configurations for the device, the names of driver files associated with the device, and so on. The device manufacturer typically provides an INF file on a disk with an adapter.

INI file Initialization file. Commonly used under Windows 3.x and earlier, INI files have been used by both the operating system and individual applications to store persistent settings related to an application, driver, or piece of hardware. In Windows and Windows NT, INI files are supported for backward compatibility, but the registry is the preferred location for storing such settings.

I/O Input/output. Two of the three activities that characterize a computer (input, processing, and output). 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 display, disk drive, or printer.

IPL Initial program load. A device used by the system during the boot process to load the operating system into memory.

IRP I/O request packet. Data structures that drivers use to communicate with each other. The basic method of communication between kernel-mode devices. An IRP is a key data structure for WDM, which features multiple layered drivers.

IRQ Interrupt request. A method by which a device can request to be serviced by the device’s software driver. The system board uses a PIC to monitor the priority of the requests from all devices. When a request occurs, a microprocessor suspends the current operation and gives control to the device driver associated with the interrupt.

ISA Industry Standard Architecture. An 8-bit (and later, a 16-bit) legacy expansion bus that provides a buffered interface from devices on expansion cards to the PC internal bus.

ISDN Integrated Service Digital Network. A set of communications standards that enables a single phone line or optical cable to carry voice, digital network services, and video.

L

LAN Local area network. A group of computers and other devices dispersed over a relatively limited area and connected by a communications link that enables any device to interact with any other device on the network. Compare with WAN.

LBA Logical block address. A unit of data supplied or requested by a host computer.

legacy Any feature in the system based on older technology for which compatibility continues to be maintained in other system components.


M

Microsoft DirectShow A cross-platform API for developers of multimedia applications that provides a user-mode connection and Stream architecture to support high-quality digital video, high-fidelity audio, and special effects.

Microsoft DirectX A low-level API that provides user-mode media interfaces for games and other high-performance multimedia applications. DirectX is a thin layer, providing direct access to hardware services. DirectX takes advantage of available hardware accelerators and emulates accelerator services when accelerators are not present.

MIDI Musical Instrument Digital Interface. An industry-standard connection for computer control of musical instruments and devices. A hardware and data standard for communicating between hardware. Most references involve only the data standard, which is a byte stream used for controlling musical instruments and storing the output of such instruments.

minidriver A hardware-specific DLL that uses a Microsoft-provided class driver to accomplish most actions through functions call and provides only device-specific controls. Under WDM, the minidriver uses the class driver’s device object to make system calls.

miniport driver A device-specific kernel-mode driver linked to a Windows NT or WDM port driver, usually implemented as a DLL that provides an interface between the port driver and the system.

motherboard See system board.

MPEG Moving Picture Expert Group. Refers to one of several standard video-compression schemes. A codec for squeezing full-screen, VHS-quality digital video into a small data stream so that it can be played from a CD-ROM drive.

multifunction device A piece of hardware that supports multiple, discrete functions, such as audio, mixer, and music, on a single adapter.

multimedia Refers to the delivery of information that combines different content formats, such as motion video, audio, still image, graphics, animation, text, and so forth.

N

NDIS Network Driver Interface Specification. The interface for network drivers used in Windows and Windows NT operating systems. NDIS provides a common mechanism by which any given NDIS-compatible transport driver can communicate with any NDIS-compatible network adapter driver. Moreover, it provides for multiple transports to work over multiple network adapters by supporting multiplexing between transports and drivers.

NMI Nonmaskable Interrupt. An interrupt that cannot be overruled by another service request. A hardware interrupt is called nonmaskable if it cannot be masked by the processor interrupt flag.

NTSC National Television System Committee of the Electronics Industries Association (EIA). The standards-setting body for television and video in the United States. Sponsor of the NTSC standard for encoding color, a coding system compatible with black-and-white signals and the first system used for color broadcasting in the United States. The broadcast standard for the United States and Japan. See also PAL format and SECAM.

NTSC format A color-television format having 525 scan lines, a field frequency of 60 Hz, a broadcast bandwidth of 4 MHz, line frequency of 15.75 KHz, frame frequency of 1/30 of a second, and a color subcarrier frequency of 3.58 MHz. See also PAL format and SECAM.

O

OEM Original equipment manufacturer. Used primarily to refer to PC systems manufacturers.

OnNow A design initiative that seeks to create all the components required for a comprehensive, system-wide approach to system and device power control. OnNow is a term for a PC that is always on but appears off and that responds immediately to user or other requests.

OpenGL An operating system independent, industry-standard API for 3-D color graphics programming. Typically used for engineering, visualization, simulation, and other graphics-intensive applications.

option ROM Also expansion ROM. Optional read-only memory found on an expansion card. Option ROMs usually contain additional firmware required to properly boot the peripheral connected to the expansion card, for example, a hard drive.


P

PAL format Phase Alternation Line format. The European video standard, except for France. See also NTSC and SECAM.

PC Card A trademark of PCMCIA. A removable device that is designed to be plugged into a PCMCIA slot and used as a memory-related peripheral.

PCI 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 a display subsystem.

PCMCIA Personal Computer Memory Card International Association. Sometimes used to refer to a controller for a type of expansion card documented in the PCMCIA standards.

Plug and Play A design philosophy and set of specifications that describe hardware and software changes to the PC and its peripherals that automatically identify and arbitrate resource requirements among all devices and buses on the system. Plug and Play specifies a set of API elements that are used in addition to, but not in place of, existing driver architectures.

Plug and Play BIOS A BIOS with responsibility for configuring Plug and Play cards and system-board devices during system power up. Provides run-time configuration services for system-board devices after start-up. See also ACPI.

power management Mechanisms in software and hardware to minimize system power consumption, to manage system thermal limits, and to maximize system battery life. Power management involves trade-offs among system speed, noise, battery life, processing speed, and power consumption.

R

RAM Random access memory. Semiconductor-based memory that can be read and written by the microprocessor or other hardware devices.

RAMDAC RAM 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.

rasterization The conversion of vector graphics (images described mathematically as points connected by straight lines) to equivalent images composed of pixel patterns that can be stored and manipulated as sets of bits.

Redbook audio The data format standard for conventional audio CDs used in home stereo systems.

registry In Windows and Windows 2000, the tree-structured hierarchical database where general system hardware and software settings are stored. The registry supersedes the use of separate INI files for all system components and applications that know how to store values in the registry.

resource (1) Any sort of set from which a subset can be allocated for use by a client, such as memory or bus bandwidth. This is not the same as resources that are allocated by Plug and Play. (2) A general term that refers to IRQ signals, DMA channels, I/O port addresses, and memory addresses for Plug and Play.

resource conflict In Plug and Play device configuration, the result of more than one device sharing a nonshareable resource. Conflicts can cause the device to be partially functional or nonfunctional, or can cause the PC to malfunction completely.

S

SCSI Small computer system interface, pronounced "scuzzy." An I/O bus designed as a method for connecting several classes of peripherals to a host system without requiring modifications to generic hardware and software.

sealed case A PC system design that does not provide end-user–accessible internal expansion slots. This is the equivalent of "no user-serviceable parts inside" for consumer appliances. A sealed case can provide external expansion capabilities.

SECAM Sequential Couleur a Memoire (Sequential Color with Memory). The television standard for France, Russia, and most of Eastern Europe. As with PAL, SECAM is based on a 50-Hz power system, but it uses a different encoding process and displays 819 horizontal lines per frame at a scan rate of 25 frames per second (50 fields per second). See also NTSC and PAL format.

SMBus System Management Bus. A two-wire interface based on the I²C protocol. The SMBus is a low-speed bus that provides positive addressing for devices, as well as bus arbitration.

software device A filter in kernel streaming and DirectShow (formerly ActiveMovie) that has no underlying hardware associated with it.

Sound Blaster Hardware produced by Creative Labs, Inc., that represents for MS-DOS–based games one of the major hardware interfaces for both audio and music (specifically MIDI) data.

spin down A power-management capability in which a hard drive shuts down its spindle motor.

S-video Also Y/C video. A video signal that separates the luminance and color (Y and C) components of the signal for improved quality over composite video. The type of video signal used in the Hi8 and S-VHS videotape formats. Transmits luminance and color portions separately, using multiple wires, thus avoiding the NTSC encoding process and its inevitable loss of picture quality.

system board Also motherboard or planar. The primary circuit board in a PC that contains most of the basic components of the system.

system devices Devices on the system board, such as interrupt controllers, keyboard controller, real-time clock, DMA page registers, DMA controllers, memory controllers, FDC, IDE ports, serial and parallel ports, PCI bridges, and so on. These devices are typically integrated into the supporting chip set.


T

TAPI Telephony API. A set of Win32-based calls that applications use to control modems and telephones by routing application function calls to the appropriate service-provider DLL for a modem.

telephony Telephone technology.

U

UART Universal Asynchronous Receiver/Transmitter. A module composed of a circuit that contains both the receiving and transmitting circuits required for asynchronous serial communication.

Unimodem Universal modem driver. A driver-level component that uses modem description files to control its interaction with the communications driver.

USB 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.

user mode The nonprivileged processor mode in which application code executes, including protected subsystem code in Windows NT.

V

VBI Vertical blanking interval. The time interval between television fields needed for the scanning gun to move from the bottom of the screen to the top for the start of the next field.

VGA Video graphics array. A video adapter that supports 640 × 480-pixel color resolution. A video display standard for boot devices under Windows operating systems.

VxD Virtual device driver. A device driver that runs at the privileged ring 0 protected mode of the microprocessor. 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

WAN Wide area network. A communications network that connects geographically separated areas. Compare with LAN.

warm docking A method of removing or installing a mobile system in a docking station by which the computer can be docked or undocked while in a reduced power state, such as suspend.

WDM Windows Driver Model. A driver model based on the Windows NT driver model that is designed to provide a common architecture of I/O services for both Windows and Windows NT for specific classes of drivers. These driver classes include USB and IEEE 1394 buses, audio, still-image capture, video capture, and HID-compliant devices such as USB mice, keyboards, and joysticks. Provides a model for writing kernel-mode drivers and minidrivers, and provides extensions for Plug and Play and power management.

WHQL Windows Hardware Quality Labs. Provides compatibility testing services to test hardware and drivers for Windows. Administers testing for the "Designed for Microsoft Windows" logo programs. For more information, see the web site at http://www.microsoft.com/hwtest/.

Win32 API A 32-bit application programming interface for both Windows and Windows NT that includes operating system capabilities, security, and API routines for Windows-based applications.

Windows Refers to the Microsoft Windows 98 operating system, including any add-on capabilities and any later versions of the operating system.

Windows DDK Documents the Windows NT driver model (upon which WDM is based) and is an essential component for building WDM drivers.

WMI Windows Management Instrumentation. Extensions to WDM developed for Windows NT 5.0 and Windows 98 to provide an operating system interface through which instrumented components can provide information and notifications.

workstation In general, a powerful computer with considerable calculating and graphics capabilities.

Y

YcrCb See YUV.

YUV The method of color encoding for transmitting color video images while maintaining compatibility with black-and-white video. Uses less bandwidth than the three separate video signals in an RGB video transmission. Consists of two major components: luminance (Y), which corresponds to the brightness of an image pixel, and chrominance (UV or CrCb), which corresponds to the color of an image pixel.

Z

Zero Administration initiative for Windows Also Zero Administration initiative. An initiative that focuses on improving Windows and Windows NT for maximum automation of administrative tasks with centralized control and maximum flexibility.


Legacy Plug and Play Guidelines

A Technical Reference for Legacy PCs and Peripherals for the Microsoft® Windows ® Family of Operating Systems

Version 1.0 – May 16, 1999

Intel Corporation and Microsoft Corporation

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

Intel Corporation and 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.

Intel and Microsoft do not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Intel and Microsoft disclaim 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, Intel and Microsoft do 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. Intel and 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.

ActiveX, BackOffice, DirectShow, DirectX, Microsoft, MS-DOS, NetShow, 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.

Intel and Pentium are registered trademarks, and Intel486, MMX, and Xeon are trademarks of Intel Corporation.

Other product and company names herein may be the trademarks of their respective owners.

© 1997–1999 Intel Corporation and Microsoft Corporation. All rights reserved.


Welcome

This guide is for engineers who build personal computers, expansion cards, and peripheral devices that will be used with the Microsoft® Windows® 32-bit operating systems and that incorporate legacy components. The specific focus of this guide is Plug and Play configuration of resources for the following system components:

  • Industry Standard Architecture (ISA) bus and devices
  • Serial ports and devices
  • IEEE 1284-based parallel ports and devices
  • Keyboard and mouse ports and devices

Important: In general, it is strongly recommended that system designers implement Plug and Play for Windows 2000 and Windows 98 based on the requirements defined in Advanced Configuration and Power Interface Specification, Version 1.0 or later (ACPI 1.0), plus the driver guidelines defined in the Microsoft Windows 2000 Driver Development Kit (DDK).

In addition, designers are strongly encouraged to seek legacy-free alternatives for system design, avoiding the ISA bus because of the throughput bottlenecks and resource limitations of ISA design.

However, it is recognized that to meet some customer requirements, system manufacturers must provide some systems that support the legacy ISA bus. The goal of this document is to provide guidelines for legacy hardware design that will result in the optimal user experience when the hardware is used with the Windows family of operating systems.

This guide is a supplement to the legacy Plug and Play specifications (available at http://www.microsoft.com/hwdev/respec/pnpspecs.htm), and the driver implementation guidelines defined in the Microsoft Windows 95 DDK. All material in this guide has previously appeared in the following documents:

  • PC 97 Hardware Design Guide (Microsoft Press®, 1997; ISBN 1-57231-381-1)
  • PC 98 System Design Guide (Microsoft Press, 1997; ISBN 1-57231-716-7)
  • PC 99 System Design Guide (Microsoft Press, 1998; ISBN 0-7356-0518-1)


Legacy Plug and Play – How to Use This Guide

How to Use This Guide

This guide is divided into several chapters, with appendixes that list detailed settings.

Chapter | Contents
Chapter 1, "Basic Legacy Plug and Play" | Defines basic specifications and guidelines for implementing legacy Plug and Play.
Chapter 2, "ISA Plug and Play" | Provides specific guidelines for implementing Plug and Play ISA, for the computer system and for individual devices.
Chapter 3, "I/O Ports and Devices" | Provides Plug and Play guidelines for legacy serial and parallel ports and for legacy mouse and keyboard connectors.
Appendix A, "IRQ, DMA, and I/O Port Addresses" | IRQ, DMA, and I/O Port Addresses
Appendix B, "Device Identifiers" | Lists compatible IDs for legacy and ISA devices.

This guide is co-authored by Intel Corporation and Microsoft Corporation.

Additional information about hardware design is available from Intel Corporation at http://developer.intel.com.

Additional information about hardware design is available from the Microsoft web sites at http://www.microsoft.com/hwdev/.


Conventions Used in This Guide

The following conventional terms are used throughout this guide.

Add-on devices

Devices that are traditionally added to the base server system to increase functionality, such as audio, networking, graphics, and so on. Add-on devices fall into two categories: devices built onto the system board set and devices on expansion cards added to the system through a system-board connector such as Peripheral Component Interconnect (PCI).

Intel Architecture

Refers to computers based on 64-bit and 32-bit microprocessors that use the Intel Architecture instruction set, such as Intel® Pentium®, Intel Pentium with MMX™ technology, Pentium Pro, Pentium II, Pentium II Xeon™, or compatible processors. MMX technology refers to Intel’s media-enhancement technology that includes new instructions added to the Intel Architecture instruction set.

Legacy

Refers to any feature in the system based on older technology for which compatibility continues to be maintained in other system components.

System devices

Also on-board devices. Refers to devices on the system board set such as interrupt controllers, keyboard controller, real-time clock, direct memory access (DMA) page registers, DMA controllers, memory controllers, floppy disk controller (FDC), AT-Attachment (ATA) ports, serial and parallel ports, PCI bridges, and so on. In today’s servers, these devices are typically integrated with the supporting chip set.

Windows

Refers to the Microsoft Windows 95 or Windows 98 operating systems, including any add-on capabilities and any later versions of the operating system.

Windows 2000

Refers to the Microsoft Windows 2000 operating system, including any add-on capabilities and any later versions of the operating system.

For a list of acronyms and definitions of technical terms, see the Glossary.


References and Resources

The following represents some of the information resources, services, and tools available to help build hardware optimized to meet the requirements defined in this guide. This section also lists technical references for the specifications cited in this guide.

Information Resources

Intel developer information

http://developer.intel.com

Microsoft hardware developer information

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

Microsoft Developer Network (MSDN) Professional Subscription

Phone: (800) 759-5474
Outside North America: (510) 275-0763
Fax: (510) 275-0762
http://msdn.microsoft.com/

Technical References

Advanced Configuration and Power Interface Specification, Version 1.0

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

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

Microsoft Platform SDK, Windows 95 DDK, and Windows 2000 DDK

Provided through MSDN Professional subscription; http://msdn.microsoft.com/subscriptions/

Microsoft Windows Hardware Compatibility List (HCL)

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

Plug and Play specifications

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


Chapter 1 Basic Legacy Plug and Play

This chapter defines the basic specifications and implementation guidelines for legacy Plug and Play.

For information about Plug and Play drivers support under Windows 95, see the Windows 95 DDK. Plug and Play for VxD drivers under Windows 98 should also follow the guidelines defined in the Windows 95 DDK.

For information about Plug and Play support under Windows 2000, see the Windows 2000 DDK.


Legacy Plug and Play Specifications

Each bus and device provided in the computer system must meet the current Plug and Play specifications related to its class, including requirements clarifications published for some Plug and Play specifications. For ACPI-based systems, buses and devices must also meet the requirements defined in Section 6 of the Advanced Configuration and Power Interface Specification, Revision 1.0. This specification defines the requirements for automatic device configuration, resource allocation, and dynamic disable capabilities.

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

  • Plug and Play BIOS Specification Version 1.0a

Important: This specification applies only for non-ACPI-based systems. ACPI-based systems must follow the requirements defined in ACPI 1.0.

  • Plug and Play External COM Device Specification, Version 1.0
  • Plug and Play Industry Standard Architecture (ISA) Specification, Version 1.0a
  • Clarification to Plug and Play ISA Specification, Version 1.0a
  • Plug and Play Parallel Port Device Specification, Version 1.0b
  • Plug and Play Small Computer System Interface Specification, Version 1.0

Note: Standard system devices are excluded from this requirement. The system can reserve static resources for devices such as programmable interrupt controllers (PICs) 1 and 2, 8254-2 timer, 8042 keyboard controller, real-time clock, DMA page registers, DMA controllers 1 and 2, and math coprocessor. For systems based on Intel Architecture compatible processors, these fixed resources are located at I/O addresses under 100h and can also include a Nonmaskable Interrupt (NMI).

All system-board devices must use ISA-compatible addresses. This includes devices with I/O port addresses within the reserved range 0h–0xFFh. For information about legacy system I/O addresses, see Appendix A, "IRQ, DMA, and I/O Port Addresses."


Unique Plug and Play Device IDs

Each device connected to an expansion bus must be able to supply its own unique ID. The following are the specific requirements for Plug and Play device IDs:

  • Each separate function or device on the system board must be separately enumerated; therefore, each must provide a device ID in the manner required in the current Plug and Play specification for the bus it uses.
  • If a device on an expansion card is enumerated by the BIOS, it must have a unique ID and its own resources according to the current 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.

In addition, if an OEM uses a proprietary mechanism to assign asset or serial numbers to hardware, this information must be available to the operating system using Windows hardware instrumentation technology, as defined in the Network PC System Design Guidelines, Version 1.0b or later.

The following are exceptions to the requirement for a unique Plug and Play ID:

  • Legacy devices attached to the ISA bus on the system board do not have unique Plug and Play IDs—for example, serial ports, parallel ports, or Personal System/2 (PS/2) compatible port devices. The method for device identification is defined in the Plug and Play ISA Specification, Version 1.0a, and the ACPI 1.0 specification.
  • Some multifunction devices, such as Super I/O, might include devices that do not have unique Plug and Play IDs or unique PCI subsystem IDs, but that are supported by drivers provided with 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 IDs for each function included on the device.


Option ROM Guidelines

These guidelines apply for devices that use option ROM on systems based on Intel Architecture processors, whether the device is present on the system board or provided through an expansion card.

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 Initial Program Load (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.


"PNP" Vendor Codes and Compatible IDs

All legacy devices not enumerated by the system-board interface must not use the acronym for Plug and Play, "PNP" in their vendor and device codes. The PNP vendor code is reserved for Microsoft and for vendors whose hardware is specifically assigned a particular ID. Other hardware can use a PNP code only when defining a device’s Compatible ID (CID) and only after first indicating the device’s Hardware ID in the Plug and Play header.

Use of CIDs are recommended for devices that use device drivers provided with the Windows operating system, such as a Standard PC COM Port (PNP0500).

For information about using PNP CIDs, see Appendix B, "Device Identifiers." To obtain a unique PNP vendor ID, complete the form provided at http://www.microsoft.com/hwdev/pnpid.htm.


I/O Decoding

Each device must support a unique I/O port address in the 16-bit address range. This requirement means that, at a minimum, the upper address lines (A10–A15) can be used as the device enable address, so that the device does not respond to addresses outside of the 10-bit address range.

Devices 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 this requirement.

Notice 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, Version 1.0a.


Chapter 2 ISA Plug and Play

This chapter summarizes Plug and Play requirements for any ISA legacy implementations.

In addition to ISA expansion cards, the following are also ISA devices:

  • 8042 and similar controllers, ports, keyboards, and mice
  • Direct memory access (DMA) controllers and slaves
  • Floppy disk controllers (FDCs)
  • Interrupt controllers
  • Legacy parallel and serial ports
  • Math coprocessors
  • Programmable interrupt timers (PITs)
  • VGA controllers

However, any such devices located at I/O addresses below 100h can use fixed resources and are exempt from Plug and Play requirements for unique IDs, flexible resource configuration, and dynamic disable capabilities.

For details about the interrupt request (IRQ) settings, DMA address, and I/O port addresses for specific devices, see Appendix A, "IRQ, DMA, and I/O Port Addresses."


System Requirements for Plug and Play ISA

This section summarizes the basic requirements for a PC system that includes the ISA bus.

If ISA support is included in a system, the manufacturer must implement the standards described in the following Plug and Play specifications:

  • Plug and Play ISA Specification, Version 1.0a
  • Plug and Play BIOS Specification, Version 1.0a
  • Clarifications to the Plug and Play BIOS Specification, Version 1.0a.

The Plug and Play specifications are available from the web site at http://www.microsoft.com/hwdev/respec/pnpspecs.htm.

Additional ISA clarifications and white papers related to ISA Plug and Play under the Microsoft Windows operating system are available from the web site at http://www.microsoft.com/hwdev/legacy/.

Note: Standard system devices are excluded from this requirement. The system can reserve static resources for devices such as interrupt controllers 1 and 2, 8254-2 timer, 8042 keyboard controller, real-time clock, DMA page registers, DMA controllers 1 and 2, and math coprocessor (if present). For a system based on Intel Architecture, these fixed resources are located at I/O addresses below 100H and can also include an NMI mask.


Plug and Play ISA Device Requirements

This section includes additional requirements for ISA cards, including requirements for design implementations that appear only as recommendations in the ISA specification, to ensure that such cards will perform correctly under Windows.

The information in this section is provided for manufacturers of ISA devices who want to ensure that their devices are completely compatible with Plug and Play operating systems.

For more details, see the Plug and Play ISA Specification, version 1.0a.


Plug and Play ISA Standards for Devices

Any card or bus that implements Plug and Play ISA must fully implement the standards defined in the Plug and Play ISA Specification, Version 1.0a. This specification also defines the requirements for a unique ID for each ISA device. The unique ID is used to identify the device for Plug and Play configuration.

Option ROMs for ISA Boot Devices

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.

For cards with option ROMs, the default configuration must be able to be disabled after the card has been isolated.

I/O Decoding for ISA Device

This circuit can be simple enough to limit I/O addresses to the 0h to 3FFh range, or it can be flexible enough to use the upper address regions.

The device must meet the guidelines for 16-bit I/O decoding defined in Chapter 1, "Basic Legacy Plug and Play," in this guide.

ISA IRQ Sharing

Under Windows 95/98 (but not Windows NT® 4.0 or Windows 2000), an ISA device and its driver can support IRQ sharing if resource requirements cannot be met. This capability applies only 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.
  • The IRQ line must never be driven high by the devices.
  • 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 dispatching an interrupt from VpicD, the drivers must respond to VpicD and correctly indicate 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.

Deterministic Values for Unimplemented Registers

Any unimplemented registers in the range 00h–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.

Correct Identifiers for ISA Devices

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 completing the form provided at http://www.microsoft.com/hwdev/pnpid.htm)
  • A company-unique Product ID (assigned by the manufacturer)

The specification requires that this Product ID 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 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 those cases, the user might install a Plug and Play card but will not receive 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 system.

BIOS Reporting or Serial ID for System Board Devices

A peripheral ISA device implemented on the system board can use a fixed Serial ID (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 requirements for a unique Serial ID as 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.

PNP Suffixes and Compatible Device IDs

Device IDs that use the three-character PNP suffix are allowed only in the Compatible Device ID field and cannot be used as Device ID or Logical Device ID fields. The exception would be the device to which the PNP-based ID was originally assigned.

Resource data describe 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 content 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 (Card Select Number [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.

Option ROMs for Boot Devices

Plug and Play ISA expansion cards that contain boot devices require some special considerations to properly boot the system. The system must implement support for Plug and Play ISA boot devices and option ROMs as described in the Plug and Play BIOS specification.

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 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 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.


Chapter 3 I/O Ports and Devices

This chapter presents guidelines for legacy I/O ports and devices, including serial and parallel ports.

Legacy Serial Port

This section defines requirements for legacy serial ports.

A 16550A buffered Universal Asynchronous Receiver/Transmitter (UART) or equivalent buffered legacy serial port is the standard implementation. For acceptable performance under Windows, the device must be able to support 115.2K baud.

A legacy serial port must provide flexible resource configuration and complete dynamic disable capabilities as defined in the Plug and Play External COM Device Specification, Version 1.0.

These are the recommended resource settings for legacy serial devices:

  • Four I/O locations for each port, where the standard ISA I/O addresses are 3F8h, 2F8h, 3E8h, 2E8h. Using the standard addresses ensures the proper functioning of software that directly addresses these locations.
  • Two IRQ signals, where the standard is programmable interrupt controller-based (PIC-based) IRQ 3 and IRQ 4. Using 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: PIC-based IRQ 4 and IRQ 11
  • For serial port B: PIC-based IRQ 3 and IRQ 10

An infrared (IR) adapter 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 IRQ sharing can be implemented under Windows if the minimum resource requirement cannot be met.

Important: Conflict resolution for legacy serial port must ensure the availability of at least one serial port. In the event of an irreconcilable conflict with other serial ports on the system, a legacy serial port must be capable of being disabled by Plug and Play software. This allows at least one of the two conflicting serial ports to operate correctly.


Legacy Parallel Port

This section presents guidelines for legacy parallel ports.

A legacy parallel port must provide flexible resource configuration following the Plug and Play Parallel Port Device Specification, Version 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 legacy parallel devices, the following are the minimum resource requirements for each parallel port on the system:

  • Required: Support ISA I/O addresses of 378h and 278h, plus 3BC or a vendor-assigned I/O address. Using these standard I/O addresses ensures proper functioning of software written for operating systems that directly address these locations.

Recommended: Map the base I/O address to four additional locations.

  • Required: Support PIC-based IRQ 5 and IRQ 7. Using 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 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 extended capabilities port (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, allowing Windows to assign the IRQ and DMA channel.

On Intel Architecture systems, the operating system considers the parallel port base address (/) stored in the first BIOS Data Area (BDA) locations to be LPT1. The address stored in the second location is LPT2, and so on. On RISC-based systems, the information is in the ARC tree. On all ACPI-based systems, the information is obtained through the ACPI tree.

EPP Support and Restricted I/O addresses

Some enhanced parallel port (EPP) implementations require eight contiguous I/O ports. If EPP support is implemented, the hardware cannot use the ISA I/O address 3BCh as a base I/O address because VGA devices require use of port 3C0h.

Compatibility, Nibble Mode, and ECP Protocols

Support for a parallel port must include, at a minimum, the compatibility-mode and nibble-mode protocols required by the IEEE 1284-1994 specification. This allows other IEEE 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.

Recommended: Enable ECP by default.

IEEE 1284 Port Connector Specifications

IEEE 1284-I–compliant ports use a standard DB25 connector found on existing system parallel port designs. This is called an IEEE 1284-A connector in the specification.

IEEE 1284-II–compliant ports use an IEEE 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, connector shell, and latch assembly. The IEEE 1284 specification recommends an IEEE 1284-C connector for all new ports and devices.

Plug and Play Device IDs for IEEE 1284 Peripherals

The device ID is described fully in the IEEE 1284 specification. All characters in the device identification string must consist only of ASCII values 20h–7Fh. The device identification string consists of a leading zero (0), a hexadecimal value that represents the length of the string, and then a set of fields in ASCII that have a unique identification string.

In addition to the requirements specified in Plug and Play Parallel Port Device Specification, Version 1.0b, the device ID string must contain the following keys, at minimum. The keys are case-sensitive and can be abbreviated in INF files as indicated.

Key | Abbreviated string
MANUFACTURER | MFG
MODEL | MDL
CLASS | CLS
DESCRIPTION | DES

All MANUFACTURER and MODEL key values must remain unique for each manufacturer. All MANUFACTURER, MODEL, CLASS, and DESCRIPTION key values must remain static for a specific unit, where ID 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 ID. 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 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 DDK and Windows 2000 DDK.

Compatible ID Key for Parallel Device ID

The CID key in the device identification string 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.


Legacy Mouse Port and Devices

The following requirements must be met to ensure that all Plug and Play requirements are met and that built-in Microsoft-supplied drivers support the pointing device. If a PS/2-style port is used, the following requirements must be met:

  • Comply in full with requirements in Personal System/2 Specification, by IBM.
  • Use an 8042 chip (or equivalent) to ensure compatibility with Windows. In most cases, the existing 8042 keyboard port is sufficient; the chip initiates a PIC-based IRQ 12 interrupt when the pointing device is connected.
  • Support PCI-based IRQ 12 to ensure the proper functioning of software written for legacy systems that use this IRQ signal.
  • Return expected codes, including send ID (0F2h) and response acknowledgement (ACK) (0FAh), plus 1-byte ID.


Legacy Keyboard Port and Devices

If a PS/2-style keyboard port is used, it must meet the following requirements, which ensure that all Plug and Play requirements are met and that built-in Microsoft-supplied drivers support this device.

  • Support IRQ 1 on Intel Architecture to ensure the proper functioning of software written for legacy systems, which expect to use this IRQ signal.
  • Map the I/O address ports to 60h and 64h.
  • Return expected scan codes, including send ID (0F2h) and response ACK (0FAh), plus 2-byte ID.


Legacy FDC

The following resource requirements must be met for each legacy FDC device on the system:

  • 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 FDC supports block data transfers to memory using DMA controllers

These resources cannot be shared among devices of the same type.

The FDC must be capable of being configured, relocated, and disabled. For example, if the legacy FDC is located on the system board and an adapter 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 adapter.

If the legacy FDC is located on an expansion card, the expansion card must allow independent dynamic disabling of the FDC and the hard disk controller. In this case, the adapter will continue to function if the FDC is disabled because of conflicts.


Appendix A IRQ, DMA, and I/O Port Addresses

This appendix lists resource assignments for IRQ, DMA, and I/O port addresses used by built-in devices on legacy system boards.

Fixed Interrupts

See "ISA Interrupts" in Appendix A of PC 2001 System Design Guide.

Legacy DMA Assignments

See "Legacy ISA DMA Assignments" in Appendix A of PC 2001 System Design Guide.

Legacy I/O Address Assignments

See "Legacy ISA I/O Address Assignments" in Appendix A of PC 2001 System Design Guide.


Appendix B Device Identifiers

This appendix lists CIDs for Plug and Play vendor IDs and device IDs.

Note: For non-BIOS enumerated ISA devices, new vendor IDs must be registered by completing the form provided at http://www.microsoft.com/hwdev/pnpid.htm or by sending mail to ihv@microsoft.com with "PNPID" in the subject line.

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 a three-character vendor code. The PNP vendor code is reserved for Microsoft and can be used only when defining a device’s CID after indicating the device’s Hardware ID in the Plug and Play header.

Use of CIDs is strongly recommended for devices that use inbox device drivers, such as a "Standard PC COM Port" (PNP0500).

The following example output of a Plug and Play header is provided as a reference for the Microsoft Windows operating system.

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 Windows 95/98 default driver. Windows 95/98 also provides the option of using a manufacturer-supplied disk 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 repeatedly requesting the default driver or a manufacturer’s disk for the remaining devices on the adapter.

When an INF file is used in this manner for default driver selection, it must link the Hardware ID (XXX0000) to the appropriate compatible device driver from the Windows 95/98 distribution CD or installation disks. If this is not done, Windows 95/98 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.


Generic Windows Device IDs

Many devices, such as the interrupt controller or the keyboard controller, have no standard Extended Industry Standard Architecture (EISA) ID. Also, a set of compatible devices, such as video graphics array (VGA) and Super VGA (SVGA), 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 (PNP) to identify various devices that do not have existing EISA IDs. Microsoft 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 | Small computer system interface (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 Windows Sound System-compatible device (obsolete; use PNPB0xx instead)


Interrupt Controllers

Device ID | Description
PNP0000 | AT interrupt controller
PNP0001 | EISA interrupt controller
PNP0002 | MCA interrupt controller
PNP0003 | Advanced Protocol Interrupt Controller (APIC)
PNP0004 | Cyrix SLiC MP interrupt controller


Timers

Device ID | Description
PNP0100 | AT timer
PNP0101 | EISA timer
PNP0102 | MCA timer


DMA

Device ID | Description
PNP0200 | AT direct memory access (DMA) controller
PNP0201 | EISA DMA controller
PNP0202 | MCA 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 keyboard A01 (106-key)
PNP0321 | Japanese keyboard (101-key)
PNP0322 | Japanese AX keyboard
PNP0323 | Japanese keyboard 002/003 (106-key)
PNP0324 | Japanese keyboard 001 (106-key)
PNP0325 | Japanese Toshiba desktop keyboard
PNP0326 | Japanese Toshiba laptop keyboard
PNP0327 | Japanese Toshiba notebook keyboard
PNP0340 | Korean keyboard (84-key)
PNP0341 | Korean keyboard (86-key)
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 | Extended capabilities port (ECP) printer port


Serial Devices

Device ID | Description
PNP0500 | Standard PC COM port
PNP0501 | 16550A-compatible COM port
PNP0502 | Multiport serial device (non-intelligent 16550)
PNP0510 | Generic IrDA-compatible device
PNP0511 | 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 Integrated Device Electronics (IDE) supporting Device Bay specifications
PNP0700 | PC standard floppy disk controller (FDC)
PNP0701 | Standard FDC supporting Device Bay specification


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 (Mach 64)
PNP0917 | Reserved by Microsoft
PNP0918 | Matrox MGA
PNP0919 | Compaq QVision 2000
PNP091A | Tseng W128
PNP0930 | Chips & Technologies SVGA
PNP0931 | Chips & Technologies Accelerator
PNP0940 | NCR 77c22e SVGA
PNP0941 | NCR 77c32blt
PNP09FF | Plug and Play monitors (VESA display data channel [DDC])


Peripheral Buses

Device ID | Description
PNP0A00 | ISA bus
PNP0A01 | EISA bus
PNP0A02 | MCA bus
PNP0A03 | Peripheral Component Interconnect (PCI) bus
PNP0A04 | VESA/VL-bus
PNP0A05 | Generic Advanced Configuration and Power Interface (ACPI) bus
PNP0A06 | Generic ACPI Extended I/O (EIO) bus


Real-Time Clock, BIOS, and 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 | System board
PNP0C02 | General ID for reserving resources required by Plug and Play system board registers (not specific to a particular device)
PNP0C03 | Plug and Play BIOS event notification interrupt
PNP0C04 | Math co-processor
PNP0C05 | Advanced Power Management (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
PNP0C08 | ACPI system board hardware
PNP0C09 | ACPI embedded controller
PNP0C0A | ACPI control method battery
PNP0C0B | ACPI fan
PNP0C0C | ACPI power-button device
PNP0C0D | ACPI lid device
PNP0C0E | ACPI sleep-button device
PNP0C0F | PCI interrupt link device
PNP0C10 | ACPI system indicator device
PNP0C11 | ACPI thermal zone
PNP0C12 | Device Bay Controller (DBC)
PNP0C13 | Plug and Play BIOS (used when ACPI mode cannot be used)


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 | Microsoft PS/2-style 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/16-MB
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-bit 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-MB ISA
PNP816D | NCR Token-Ring 16/4-MB 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 (RNA) driver
PNP8387 | RNA point-to-point protocol (PPP) driver
PNP8388 | Reserved for Microsoft networking components
PNP8389 | Peer IrLAN IR driver (Microsoft-supplied)
PNP8390 | Generic network adapter


SCSI and 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, and Multimedia

Device ID | Description
PNPB000 | Sound Blaster 1.5 sound device
PNPB001 | Sound Blaster 2.0 sound device
PNPB002 | Sound Blaster Pro sound device
PNPB003 | Sound Blaster 16 sound device
PNPB004 | Thunderboard-compatible sound device
PNPB005 | Adlib-compatible frequency modulation (FM) synthesizer device
PNPB006 | MPU401 compatible
PNPB007 | Microsoft Windows Sound System-compatible sound device
PNPB008 | Compaq Business Audio
PNPB009 | Plug and Play Microsoft Windows Sound System device
PNPB00A | MediaVision Pro Audio Spectrum (Trantor SCSI-enabled, Thunder Chip-disabled)
PNPB00B | MediaVision Pro Audio 3-D
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/gameport


Modem

Modems

Device ID | Description
PNPC000 | Compaq 14400 modem (TBD)
PNPC001 | Compaq 2400/9600 modem (TBD)


Design Guidelines for PC Card and CardBus

A Technical Reference for PC Card and CardBus Controllers and Devices for the Microsoft® Windows® Family of Operating Systems

Addendum to PC 2001 System Design Guide

Version 1.1 – April 12, 2000

Intel Corporation and Microsoft Corporation

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

Intel Corporation and 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.

Intel and Microsoft do not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Intel and Microsoft disclaim all expressed 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, Intel and Microsoft do 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. Intel and 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.

Direct3D, DirectDraw, DirectShow, DirectX, Microsoft, MS-DOS, 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.

Indeo, Intel, and Pentium are registered trademarks of Intel Corporation.

Other product and company names herein may be the trademarks of their respective owners.

© 1998-2000 Intel Corporation and Microsoft Corporation. All rights reserved.

Revision History

Revision Number | Publication Date | Comments
1.00 | March 20, 2000 | Release. Extracted from PC 2001 System Design Guide, rev. 0.7.
1.1 | April 12, 2000 | Clarifications: PCCard-2: Reinstated PCCard-8: Required for PC 2001 PCCard-19: Removed "or later" from PC Card Standard, Release 7 cite PCCard-22: Terminology change: LVE to VPE Added trademark for DirectDraw


Introduction

This design guide — which is provided as an addendum to PC 2001 System Design Guide — presents requirements for PC Card controllers and devices designed to work with the Microsoft® Windows® family of operating systems. This includes requirements for 16-bit PC Card, previously referred to as Personal Computer Memory Card International Association (PCMCIA) cards, CardBus cards, and PC Card socket controllers.

This material was originally published in PC 99 System Design Guide, co-authored by Intel and Microsoft. Because the support in the Windows family of operating systems has not changed, and is not expected to change in the future, this addendum has been created as a stand-alone reference.

Please note that the requirements described in this addendum are incorporated as part of the PC 2001 requirements by reference from within PC 2001 System Design Guide.

Note: PC Card requirement changes from PC 99 System Design Guide are indicated as Notes in this guide. These changes include the following:

  • Clarification of CardBus power management requirements, with definition of requirements for wake-from-D3cold and Vaux (requirement 19)
  • Update of specification references for PC Card Standards
  • Clarification of ZV requirement: changed to "if implemented" (requirement 2)

Microsoft Windows Millennium Edition (Windows Me), Windows 98, and Windows 2000 Professional support 16-bit PC Card I/O cards and CardBus I/O cards. Memory 16-bit PC Card cards are supported only as legacy devices. For any PC Card device to work effectively with Windows 98/Me or Windows 2000, the manufacturer must implement a minimum set of tuples documented in the PC Card Standard. Windows uses these tuples to identify and configure any 16-bit PC Card card, and it might also use these tuples for CardBus cards.


PC Card Requirements

This set of guidelines summarizes requirements for PC Card implementation. These requirements apply to two distinct types of PC Cards: 16-bit PC Cards, and CardBus cards (which are 32-bit cards).

For each of these two types of PC Cards, requirements are defined in four different implementation areas:

  • Socket controller ("bridge") requirements
  • Host-system support requirements (such as system board and firmware)
  • Software requirements
  • Card requirements

Note that power management requirements may be included in each of these requirements categories, in keeping with the fact that power management is a system-level capability. Also note that both 16-bit PC Cards and CardBus cards can be multifunction cards (that is, cards that include multiple devices, all of which share that card’s single PC Card interface).

Each device in a multifunction PC Card—such as a CardBus card—must separately meet the power management device class specifications for its device class and be independently power managed. This means that it is not necessary for both device A and device B on the same add-on card to be idle before the system can change the power-state of one or both of these devices.

A CardBus socket can accept any of the previously mentioned PC Card types. When a CardBus socket controller interfaces with a 16-bit PC Card, the controller works differently than when interfacing a CardBus card. The list of CardBus requirements includes accommodation of 16-bit PC Cards by a CardBus socket controller


PC Card Basic Requirements

This section summarizes the basic requirements for PC Card.

PCCard-1. All devices comply with the PC Card standards

Required — PC 99:12.1

Designs for PC Card socket controllers and cards must all be based on PC Card Standard Release 7 or later.

All PC Card devices must comply with these standards.

For information about implementing R2 version cards to use only 3.3 volts, see the white paper titled "Card Voltage Requirements and the Windows Operating System" at http://www.microsoft.com/hwdev/cardbus/pccardvlt.htm.

Note: In PC 99 System Design Guide, this requirement referred to earlier versions of the standard. This guide cites the current specification. The implementation requirements remain the same.

PCCard-2. System and ZV-compatible 16-bit PC Cards comply with ZV standard definitions

Required - PC 99:12.2

The PC Card standards define the requirements for Zoomed Video (ZV) cards and system support.

Note: In PC 99 System Design Guide, Zoomed Video support was required. Zoomed Video is not required for PC 2001, but if it is implemented, it must support PC Card standards.


PC Card Socket Controller Requirements

This section summarizes requirements and standards for socket controllers.

PCCard-3. Controller supports industry-standard ExCA register set

Required — PC 99:12.3

The built-in software supporting 16-bit PC Card cards in Windows includes drivers for the industry-standard Exchangeable Card Architecture-compatible (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 register set and therefore 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.

PCCard-4. System maintains mapping of IRQ Routing Register bits to system interrupt vectors

Required — PC 99:12.4

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.

PCCard-5. IRQ connections can be determined by using the 0805 register

Required — PC 99:12.5

Windows uses the 0805 register on CardBus controllers to determine which ISA IRQs are connected to the controller. This register must engage (drive low when the IRQ is asserted) the corresponding ISA IRQ when programmed with a value. It must deselect the IRQ (float high) when programmed at zero (0). This behavior must be achieved without requiring the operating system to program any non-standard registers.

PCCard-6. CardBus controllers support both ISA and PCI interrupts

Required — PC 99:12.6

PC Card software dynamically configures the bridge to use ISA interrupts for 16-bit PC Card cards and to use Peripheral Component Interface (PCI) interrupts for CardBus cards. As defined in earlier requirements, CardBus controllers must maintain mapping of IRQ routing. Also, notice that systems implementing CardBus controllers must fully support PCI 2.2 as well as additional PCI requirements for IRQ routing as defined in PC 99 System Design Guide and PC 2001 System Design Guide.

To ensure that the Windows operating system can correctly assign ISA IRQs to 16-bit PC Cards, CardBus controllers that have parallel ISA IRQ mode must have all ISA IRQs pins, except IRQ 0 (timer), 1 (keyboard), 6 (floppy), 8 (CMOS), 13 (math coprocessor). It is recommended that system vendors using parallel ISA IRQ mode always connect ISA IRQs 3, 4, 5, 7, 9, 10, 11, 12, 14, 15 and not cross wired them.

Note: Vendors using serialized IRQ mode only need to connect the serial IRQ pin, and the ISA IRQ information will be sent to the PCI chip set serially; the ISA IRQ information can specify any of IRQ 0–15.

PCCard-7. System supports industry-standard definition for CardBus bridges

Required — PC 99:12.7

Systems must support the definition in PC Card Standard Release 7 (or later) PC Card Host System Specification (Volume 11), PCI-to-CardBus Bridge Register Description (Section 4) for CardBus controllers (PCI-to-CardBus bridges). This definition includes a common PCI Configuration Space header assigned the Header Type field value of 82h.

Windows supports this specification. Any controller features that are not part of this specification will not be used in standard drivers. The BIOS is responsible for any hardware initialization or setup required to make the controller comply with this specification or other requirements in this document.

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.

Note: In PC 99 System Design Guide, this requirement referred to PCI to PCMCIA CardBus Bridge Register Description (Yenta specification). This guide cites the current specification as it was incorporated into the PC Card standard. The implementation requirement remains the same.

PCCard-8. BIOS initializes CardBus controller in 82365-compatible mode and supports backward compatibility

Recommended — PC 99:12.8

Note: In PC 99 System Design Guide, this item was recommended. It is required for PC 2001.

When Intel 82365–compatible modes are implemented, CardBus controllers are enumerated and configured in the same way as other PCI bus bridges. The PCI bus bridge support in Windows 98 is based on requirements for PCI interrupt routing and bridge-window configuration. Therefore, full compliance with the latest PCI specifications is required for CardBus support.

There are steps the BIOS can take to achieve backward compatibility with Windows. Specifically, the BIOS can initialize the CardBus controller in Intel 82365-compatible mode and report it as device "PNP0E03, Intel 82365-compatible CardBus controller." The requirements are as follows for BIOS POST time (CardBus controller ConfigSpace initialization):

  • Command register (offset 0x04) set to 0x07 (IOSpaceEnable, MemSpaceEnable, BusMasterEnable).
  • RegisterBaseAddress (offset 0x10) set to 0. If support for other environments is needed, such as Windows 3.1 or MS-DOS®, some other value can be set.
  • All memory and I/O windows (offset 0x1c–0x38) set to 0.
  • Interrupt Line register (offset 0x3c) set to 0xff (no IRQ assigned). If support for other environments is needed, such as Windows 3.1 or MS-DOS, an assigned IRQ line can be set. Notice, however, that this register must be set to 0xff at the time that the device is disabled by the operating system, and then set into CardBus mode. More information about BIOS enumeration is presented later in this requirement.
  • Other controller-specific initialization as required to put the controller in legacy mode.

This puts the CardBus controller into legacy mode where the Windows Socket Services driver can access it as an Intel PC Card I/O card–compatible (PCIC-compatible) controller at an I/O address, for example, 0x3e0.

Notice that the BIOS must be at least PCI 2.2-compliant and must support the $PIR Interrupt Routing Table. The $PIR table must 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.

For more information, see the white paper on CardBus host controllers and Windows compatibility at http://www.microsoft.com/hwdev/cardbus/.

PCCard-9. CardBus controllers do not share writable PCI Configuration Space bits

Required — PC 99:12.9

CardBus controllers are multifunction PCI devices, and Windows treats each function 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 16-bit PC Card interface legacy-mode Base Address Register (BAR; offset 44h in the Type 2 PCI header) is the only exception to this requirement. This BAR must be shared between the two functions in order to be compatible with the ExCA programming model.

PCCard-10. Each 16-bit PC Card memory window in CardBus controller has it own page register

Required — PC 99:12.10

For complete flexibility and support of typical configurations, CardBus controllers must support the independent location of R2 memory windows anywhere in the full system address space as recommended in the PC Card Standard Release 7 (or later), PC Card Host System Specification, PCI-to-CardBus Bridge Register specification.

Controllers that share a single page register among all 16-bit PC Card memory windows require that all 16-bit PC Card memory windows must be located within the same 16-MB block. This is often not possible with typical (16 MB) DRAM and bridge (positive-decode) configurations. The result is disabled cards.

Note: In PC 99 System Design Guide, this requirement refers to the Yenta specification. This guide cites the current specification as it was incorporated into the PC Card standard. The implementation requirement remains the same.


Plug and Play Design for 16-bit PC Card Cards

This section summarizes the Plug and Play requirements for 16-bit PC Card 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, 16-bit PC Card 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 possible configurations to the Plug and Play configuration manager. The operating system then dynamically assigns a valid configuration based on this information.

PCCard-11. Card supports required I/O card tuples

Required — PC 99:12.11

The following items must be implemented for any 16-bit PC Card I/O card that connects to a system:

  • The 16-bit PC Card card must contain:
  • The device information tuple (CISTPL_DEVICE, 01h for cards capable of 5V operation or CISTPL_DEVICE_0C, 1Ch for cards capable of 3.3V operation).
  • The Level 1 (L1) version/product information tuple (CISTPL_VERS_1, 15h).
  • The configuration tuple (CISTPL_CONFIG, 1Ah).
  • The configuration table entry tuple (CISTPL_CFTABLE_ENTRY, 1Bh).
  • A 16-bit PC Card card with more than 64 MB Common Memory must contain the extended device information tuple (CISTPL_EXTDEVICE, 09h).
  • The L1 version/product information tuple must contain the product name and manufacturer name in the product information string (TPLLV1_INFO, byte 4).
  • The product name and manufacturer name in the L1 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 ID 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 ID | 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 | L1 version/product information strings: Product information, Product name, Product number, Other manufacturer information
1Ah | CISTPL_CONF | Configuration. Indicates the location of configuration registers and 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 ID. Card manufacturer ID code. Defines manufacturer for this card.
21h | CISTPL_FUNCID | Function ID. 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 16-bit PC Card I/O cards, but the device type must be NULL.

The L1 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 string and product name string to construct the device ID for that card. It also scans through the tuple, starting at the very beginning and continuing to the end of the product name string.

The information gathered from the L1 version/product information tuple is used to construct the unique device ID. Because the optional third and fourth strings in the tuple are not used in the unique ID, 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 ID tuple (CISTPL_MANFID, 20h) and the function ID tuple (CISTPL_FUNCID, 21h) add extra flexibility to a PC Card that connects to the PC:

  • The manufacturer ID tuple provides unique information about the card manufacturer. This code is registered with PCMCIA. Windows uses the manufacturer ID tuple as one source for creating a 16-bit CRC used in the construction of the device ID.
  • The function ID 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 ID tuple internally to determine what type of device is on the PC Card.
PCCard-12. Configuration table entry tuples listed in priority order

Required — PC 99:12.12

Configuration table entry tuples are placed in the preferred order for configuring the device. Windows processes the tuples in the order they are placed in the Card Information Structure (CIS). From these tuples, Windows creates a 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.3-volt configurations, if they are supported by the system, over 5-volt configurations, regardless of the order of the configuration table entry tuples (CISTPL_CFTABLE_ENTRY).

PCCard-13. Card specifies maximum configuration options

Required — PC 99:12.13

Many older PC Cards specified fixed configurations in order 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 describe its maximum configurability, ruling out configurations not supported by the hardware.

If fixed configurations must be provided for an operating system other than Windows, there must be one or more entries that specify the maximum configurability that the hardware can handle. An example of "maximum configurability" is to specify "any IRQ" rather than only IRQ 3 or IRQ 4.


Plug and Play Design for CardBus

This section summarizes the Plug and Play requirements for CardBus cards. CardBus was designed as a combination of the 16-bit PC Card and PCI. The goal is to gain the benefits of PCI in a PC Card format. Consistent with this goal, Windows support for CardBus places specific requirements on CardBus cards.

PCCard-14. Configuration Space meets Common Silicon Guidelines

Required — PC 99:12.14

The Common Silicon Guidelines are defined in Section 2.1 of the PC Card Standard Guidelines, Volume 10.

Note: PC 99 System Design Guide cited Section 2.6. This guide corrects the citation and provides the following additional notes:

  • The standard for CardBus defines a PCI "Type-2" configuration space that is defined in Section 4.5 of Volume 11 (PC Card Host System Specification) of the PC Card Standard Release 7. The Type-2 CardBus-bridge PCI header structure was defined to be as similar to the Type-1 (PCI-to-PCI bridge) header as possible. Type-2 and Type-1 PCI headers differ only in that the Type-2 header allows 4-byte resolution in I/O Base and Limit registers, while the Type-1 header supports a coarser 4K resolution for these registers.
  • CardBus cards include normal Type-0 PCI headers, with certain provisions. The quadword register located at 0x28 is used as a pointer to the CardBus Card Information Structure (CIS). CardBus cards must also implement certain Command and Status Register fields that are optional for PCI devices. CardBus cards must also provide a Memory BAR for every I/O BAR provided (so that I/O windows can be memory-mapped).
  • Section 2.1.3.4 of Volume 10 (Guidelines) of the PC Card Standard Release 7 details the common silicon guidelines to which CardBus cards must adhere.

To maintain compatibility with existing PCI system software and drivers, Windows will support only CardBus cards whose Configuration Space is designed to meet the Common Silicon Guidelines. This is a requirement because CardBus configuration is performed by the PCI software, which can deal with all aspects of PCI topology configuration, including bridging. Without the allocated fields, the cards cannot be fully treated as PCI devices and 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 card manufacturer. The PCI SIG allocates unique IDs.
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 | This read-only field is defined in PCI 2.2. It describes what type of device the card is.
Max_Lat Min_Gnt | These read-only fields specify the desired settings for Latency Timer values according to PCI 2.2. A value of 0 indicates 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.
PCCard-15. RESERVED fields comply with PCI 2.2

Required — PC 99:12.15

The CardBus specification also lists two RESERVED fields (offset 2C in the Configuration Space), which have since been defined in PCI 2.2. These fields 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
PCCard-16. CardBus card implements required and recommended tuples

Required — PC 99:12.16

For CardBus, Windows also requires the same set of card tuples recommended in the PC Card guidelines, as summarized in the following table.

Required CardBus Tuples

Tuple ID | Tuple code | Comments
04h | CISTPL_CONFIG_CB | —
05h | CISTPL_CFTABLE_ENTRY_CB | —
07h | CISTPL_BAR | —
13h | CISTPL_LINKTARGET | Required as first tuple in PC Card standard.
15h | CISTPL_VERS_1 | —
20h | CISTPL_MANFID | —
FFh | CISTPL_END | Required as end-of-chain tuple in PC Card standard.
21h | CISTPL_FUNCID | Recommended in PC Card standard; required for Windows operating system compatibility.


Requirements for PC Card

This section summarizes additional requirements for PC Card.

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 PC 99 System Design Guide and PC 2001 System Design Guide.

PCCard-17. Socket controller complies with device class power management reference specification

Required — PC 99:12.17

This applies for both 16-bit PC Card-only controllers and CardBus controllers.

The PC Card Controller Device Class Power Management Reference Specification, Version 1.0 or later, 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 wake-up event definitions for the class, for example, whether card insertion should wake the system.

PCCard-18. 16-bit PC Card cards implement power-related events using ReqAttn bit and #STSCHG mechanism

Required — PC 99:12.18

Any 16-bit PC Card card that is capable of signaling a wake-up event to the system, as defined in the device class power management reference specification for its class, must implement the ReqAttn bit and its associated enable bit in the Extended Status register, and must signal on the #STSCHG line.

PCCard-19. CardBus controllers and cards implement PCI and CardBus power management specifications

Required — PC 99:12.19

PCI-to-CardBus bridges and CardBus cards must comply with the requirements defined in Section 3 (PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges) of the PC Card Standard, Release 7. This specification describes the CardBus power-management interface hardware, as well as proper software use of these hardware mechanisms.

The CardBus card must use the CSTSCHG pin to signal wake-up events. This is because there is no PME# pin on the CardBus interface, and the CardBus card must use PME_EN in the card’s Configuration Space to enable wake-up events. Specifically, setting the PME_EN bit in the card’s Configuration Space must provide the same behavior as setting both the GWAK and WKUP bits in the card’s Function Event Mask register.

If wake-from-D3cold is implemented in a platform, the following are required:

  • Associated CardBus controller must support PME# assertion from D3cold.
  • Associated socket must supply sufficient Vaux power to support the card in its D3cold state.

This requirement must be independently met by each enabled D3cold-wake-capable CardBus socket in the system, as defined in the host system chapter of PC Card Standard, version 7.

Power management requirements for 16-bit PC Card cards are defined earlier in requirement 18.

Note: This guide defines these new power management requirements over what was required in PC 99 System Design Guide:

  • Section 3 (PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges) of the PC Card Standard, Release 7 as a new specification for CardBus cards. (PC 99 requirements called only for PCI-PM 1.0.)
  • Wake-from-D3cold support for controller and socket.


Device Drivers and Installation for PC Card

This section summarizes requirements for PC Card device drivers.

PCCard-20. No user intervention required for correctly installing devices

Required — PC 99:12.20

The user must not be required to perform any device-installation action other than to insert disks that contain drivers and other files.

PCCard-21. Device is immediately functional without restarting the system

Required — PC 99:12.21

The user must be able to begin using the device without having to restart the system. Device use begins either after installation is complete or whenever the device is inserted in the system.

PCCard-22. ZV-compatible PC Card driver uses DirectDraw VPE

Required — PC 99:12.22

ZV-compatible PC Card drivers must use software interfaces based on 32-bit Microsoft DirectDraw® Video Port Extensions (VPE) in order 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. VPE is part of Microsoft DirectX® APIs.

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.

Note: Since PC 99 System Design Guide, the extensions to DirectDraw APIs identified as Live Video Extensions (LVE) have been renamed Video Port Extensions (VPE). The implementation requirement remains the same.

PCCard-23. 16-bit PC Card card driver supports sharing of level-mode interrupts

Required — PC 99:12.23

CardBus systems support both 16-bit PC Card cards and CardBus cards. In this environment, interrupt sharing becomes an issue because CardBus controllers can use PCI interrupts, which are level-sensitive and sharable. To help alleviate interrupt limitations in CardBus systems, Windows operating systems can take advantage of PCI interrupt-sharing capabilities.

In cases where no ISA IRQs are available to a 16-bit PC Card card in a CardBus controller, the operating system will assign a PCI interrupt to the card. All 16-bit PC Card card drivers must "hook" the interrupt, whether it is sharable or not, before its hardware generates any interrupts.


PC Card References

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

Microsoft Windows 98 DDK and Windows 2000 DDK

http://www.microsoft.com/ddk/ or Msdn Professional membership

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.pcdesguide.org

PC Card Controller Device Class Power Management Reference Specification, Version 1.0 or later

http://www.microsoft.com/HWDev/specs/PMref/PMcard.htm

PCI Bus Power Management Interface Specification for PCI to CardBus Bridge,
Revision 1.0
PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com

PC Card Standard Release 7

PCMCIA
http://www.pc-card.com/bookstore.htm

CardBus host controllers and Windows compatibility white papers

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


Checklist for PC Card

If a recommended feature is implemented, it must meet the requirements for that feature as defined in this document.

PCCard-1. All devices comply with the PC Card standards

Required — PC 99:12.1

PCCard-2. System and ZV-compatible 16-bit PC Cards comply with ZV standard definitions

Required - PC 99:12.2

PCCard-3. Controller supports industry-standard ExCA register set

Required — PC 99:12.3

PCCard-4. System maintains mapping of IRQ Routing Register bits to system interrupt vectors

Required — PC 99:12.4

PCCard-5. IRQ connections can be determined by using the 0805 register

Required — PC 99:12.5

PCCard-6. CardBus controllers support both ISA and PCI interrupts

Required — PC 99:12.6

PCCard-7. System supports industry-standard definition for CardBus bridges

Required — PC 99:12.7

PCCard-8. BIOS initializes CardBus controller in 82365-compatible mode and supports backward compatibility

Recommended — PC 99:12.8

PCCard-9. CardBus controllers do not share writable PCI Configuration Space bits

Required — PC 99:12.9

PCCard-10. Each 16-bit PC Card memory window in CardBus controller has it own page register

Required — PC 99:12.10

PCCard-11. Card supports required I/O card tuples

Required — PC 99:12.11

PCCard-12. Configuration table entry tuples listed in priority order

Required — PC 99:12.12

PCCard-13. Card specifies maximum configuration options

Required — PC 99:12.13

PCCard-14. Configuration Space meets Common Silicon Guidelines

Required — PC 99:12.14

PCCard-15. RESERVED fields comply with PCI 2.2

Required — PC 99:12.15

PCCard-16. CardBus card implements required and recommended tuples

Required — PC 99:12.16

PCCard-17. Socket controller complies with device class power management reference specification

Required — PC 99:12.17

PCCard-18. 16-bit PC Card cards implement power-related events using ReqAttn bit and #STSCHG mechanism

Required — PC 99:12.18

PCCard-19. CardBus controllers and cards implement PCI and CardBus power management specifications

Required — PC 99:12.19

PCCard-20. No user intervention required for correctly installing devices

Required — PC 99:12.20

PCCard-21. Device is immediately functional without restarting the system

Required — PC 99:12.21

PCCard-22. ZV-compatible PC Card driver uses DirectDraw VPE

Required — PC 99:12.22

PCCard-23. 16-bit PC Card card driver supports sharing of level-mode interrupts

Required — PC 99:12.23