PC Card Standard and Windows 95: A Developer's Update

Microsoft Corporation

May 1996

Introduction

Microsoft® Windows® 95 introduced true Plug and Play support for PC Cards. The system-wide Plug and Play infrastructure offered consistent, robust configuration for PC Cards, while abstracting the bus-specific issues away.

More than a thousand Plug and Play drivers have appeared for Windows 95, and many support multiple implementations of the target hardware: ISA, PCI, and PC Card versions. Since the release of Windows 95, PC Card products designed to the February 1995 PC Card Standard have appeared in the market. These include Multiple Function Cards, 3.3V cards, cards that use DMA, and 32-bit PC Cards.

Windows is now evolving to add support for these new features. The goal for these advancements is to leverage the Plug and Play architecture's modularity and bus-independence in order to add capabilities without affecting device drivers. Driver development remains identical to that used in Windows 95, and many Plug and Play drivers that work on Windows 95 can be used unmodified to support the same controller implemented on the new multifunction or 32-bit PC Cards.

The new implementation under Windows will appear in an incremental release to Windows OEMs in mid-1996. The purpose of this paper is to provide hardware vendors and OEMs with all the information needed to support new devices in the Windows environment.

PCI-to-PC Card Bridges

After Windows 95 was released, a new type of controller appeared on the market that interfaces to the PCI bus rather than the ISA bus, referred to as a PCI-to-PC Card bridge. Interfacing this device to the system presents some difficulties, particularly with respect to interrupts. Two methods are available to connect interrupt lines to this device—one that is compatible with ISA IRQs and the other that takes advantage of the PCI interrupt mechanism. Windows requires the use of the ISA-compatible mechanism for support of PC Card 16 cards, and Windows also requires the PCI interrupt mechanism for support of PC Card 32 cards.

For PC Card 16 card support, the system design must maintain the mapping of the PCMCIA 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.

For PC Card 32 card support, the system design (including the PCI-to-PC Card 32 bridge) must fully support PCI version 2.1 plus the additional PCI Interrupt Routing Table and Bridge Window specifications.

Note   Systems that implement PCI-to-PC Card 32 bridges must implement both interrupt mechanisms to support both types of cards. The PC Card software in Windows will dynamically configure the bridge to use ISA interrupts for PC Card 16 cards and to use PCI interrupts for PC Card 32 cards.

Multiple Voltage (5V/3.3V) PC Card Support

In the next releases of Windows, 3.3V-only and 5V/3.3V cards will be supported. The voltage policy for multiple voltage cards will be to prioritize 3.3V configurations (if supported by the system) over 5V configurations, regardless of the order of the Configuration_Table_Entry tuples. Aside from this specific exception, all other prioritization of configurations will be based on the order of the Configuration_Table_Entry tuples, as was the case in Windows 95.

Windows 95 does not explicitly support multiple voltage PC Cards, but you can successfully use a 5V/3.3V card in a 5V-only system by taking advantage of the Windows 95 configuration prioritization rules. To do this, the Configuration_Table_Entry tuples for configurations that use 5V must appear before the Configuration_Table_Entry tuples for configurations that use 3.3V. Given this, Windows 95 will give priority to the 5V configurations and configure the card correctly.

Multiple Function PC Cards

Windows will support Multiple Function PC Cards (MFC cards) in a manner significantly different from how combination PC Cards are supported under the original release of Windows 95. MFC cards are not backward compatible with Windows 95. Combination cards are multifunction cards designed to the PCMCIA Release 2.1 specification.

For MFC cards, each function on the card is treated independently. Each can be configured and enabled independently, and each function's hardware must make no assumptions about whether any other function on the card is enabled, configured, or even present. Similarly, device drivers for functions on MFC cards must not make any assumptions about the existence or state of any other function that might be on the card, and device drivers must not attempt to access or configure any other function.

The sole requirement for drivers to be MFC-compatible is to share interrupts by correctly using the system-provided services for shared interrupts. For information about writing device drives, see the Windows 95 Device Driver Kit (DDK) in MSDN Professional Subscription.

MFC cards have different installation requirements than those for combination cards. Most important, there is no need for the card to have a "Multifunction" class device information file (INF). Instead, only class-specific INF files are required for each function. Each function on the MFC card will receive its own device ID according to the new ID structure defined later in this paper. For MFC functions, the string "DEV#" is added just before the manufacturer ID values, where # is the function number starting from 0.

Also, Overriding Logical Configurations are still supported, but are only required if the function's Configuration_Table_Entry tuples are incorrect.

The form of the device ID for MFC cards is the following:

PCMCIA\Manufacturer string-Product String-DEV#-XXXX-YYYY

where:

PC Card 32 Support and Windows 95

PC Card 32 (also referred to as CardBus) was designed as a combination of PC Card 16 and PCI. In integrating with the system, there are a number of compatibility issues that affect how PC Card 32 cards are supported. To minimize these compatibility issues, and to offer the most robust and feature-rich support for PC Card 32, Windows uses a combination of PC Card software and PCI software to support PC Card 32 cards.

The PC Card software is responsible for enumerating the card, configuring the voltage for the card, and handling dynamic events such as removals or other STSCHG notifications. The PCI software is responsible for configuring the device as part of the overall PCI topology, including bridging and interrupt routing issues. This combination approach offers the best compatibility with existing drivers and BIOSs, while delivering true dynamic Plug and Play support.

PC Card 32 Cards

PC Card 32 cards must fully support the PCI Configuration Space standard. Unfortunately, the PC Card 32 Standard does not allow card vendors to implement certain critical fields in the configuration space (described as "allocated" in the PC Card Standard). However, the Standard's Common Silicon Guidelines (for silicon that is common to both PCI and CardBus products) do recommend that these fields be implemented. For compatibility with Windows, the Common Silicon Guidelines for Configuration Space must be implemented.

The required "allocated" fields are listed in the Table 1.

Table 1. Required "Allocated" Fields

In addition, the PC Card 32 specification lists two fields as RESERVED (offset 2C in the configuration space), which have since been defined in the PCI v. 2.1 specification. These are also required on CardBus cards for Windows compatibility.

Table 2. Required RESERVED Fields for PC Card 32

Windows supports the same set of tuples as required by the PC Card Standard. This information is used as supplemental information for devices that are not fully described using the PCI configuration space. The required tuples are summarized in Table 3.

Table 3. Required and Recommended Tuples for PC Card 32

PC Card 32 Host Controllers

CardBus host controllers are simply a new type of PCI bridge. These controllers perform the bus bridging function between a PCI bus and the PC Card 32 bus. To smoothly integrate with the PCI standard, manufacturers of PC Card 32 controllers have developed an industry-standard definition for this type of PCI bridge. This standard defines a standard PCI header type field (82h), plus a set of required register definitions that represent the standard way for host software to interface with the controller. The Windows-based socket services drivers are written to support this standard definition, even though it might not be formally approved by the PCI SIG.

Because CardBus host controllers are PCI bus bridges, they will be supported (enumerated and configured) by the PCI software in Windows, just as other PCI bus bridges are. The PCI bus bridge support has been enhanced for the next release of Windows to support full, dynamic configuration of devices on arbitrary PCI topologies. This support is based on new requirements for PCI interrupt routing and bridge-window configuration currently in process at the PCI SIG. Because of this, full compliance with the latest PCI requirements is required for PC Card 32 support.

For backward compatibility with Windows 95, there are steps the BIOS can take. Specifically, the BIOS must initialize the CardBus controller in Intel 82365-compatible mode and report it as device PNP0E03, Intel 82365-compatible CardBus controller. The requirements for reporting this node are as follows:

• Use PNP0E03 as the device ID.
  
  
• Use PNP0E00 (generic Intel 82365-compatible controller) as the compatible ID.
  
  
• Report the device as configurable and capable of being disabled at run time.

Given the above, the PC Card drivers for Windows 95 will operate the controller as a PCIC controller. When the new CardBus PC Card software is installed, the system will recognize this ID, disable it, and reconfigure the CardBus controller to operate in full CardBus mode.

New Device IDs for I/O PC Cards

In addition to support for new features, minor enhancements relating to general PC Card support have also been made. For example, the structure of the device ID for I/O PC Cards is being modified to address a problem. The structure used in Windows 95 created an overly unique ID that reflected any and all changes to the CIS of the card and unnecessarily affected the mapping of cards to device drivers. Any tuple change required an associated change to the device information file so that Windows 95 could automatically install the device. In many cases, such as tuple bug fixes or other configuration-related changes not relevant to the device driver, this was not the desired effect.

The new method limits ID changes to only those that require a new INF. This method puts the hardware vendor in control of determining when the ID must change, based on any related INF changes that might be required.

The existing device IDs for PC Cards will continue to be used as an equivalent ID. This ensures that existing cards and INFs will continue to work unmodified. In addition, a new device ID will also be created.

The form of the new device ID is the following:

PCMCIA\Manufacturer string-Product String-XXXX-YYYY

where:

Notice that for a card to work with an existing INF, its card information structure (CIS) must contain the same Manufacturer string, Product string, Manufacturer ID, and Product ID of the card for which the INF was created. Conversely, if a new INF is required for the card, one of these CIS components must be different from that of the original card.

The list of required tuples for I/O PC Cards is not changed in this version of PC Card software.

Update on Memory Card Support

Windows 95 support for memory card is not designed to be Plug and Play as is the support for I/O cards. To maintain compatibility with the Flash File System drivers, memory cards must be supported as legacy devices. However, new memory card technologies can be supported under Windows with a protected-mode memory technology driver (MTD). The MTD can be automatically installed and loaded in the same way as Plug and Play device drivers. This is done based on the Plug and Play ID created for the memory card. The device ID for memory cards is based on the PCMCIA JEDEC ID (CISTPL_JEDEC-C, 18h).

The structure of the device ID is the following:

PCMCIA\MTD-<JEDEC_ID>

where <JEDEC_ID> consists of the PCMCIA JEDEC ID.

For an example of device IDs for memory cards, see the file MTD.INF in the \Windows\Inf directory of Windows 95.

Conclusion

Windows is supporting the PC Card standard in a compatible, Plug and Play fashion as new capabilities are introduced. Building on the bus-independent Plug and Play infrastructure in Windows 95, these advancements can be made with no impact on development of drivers or on compatibility with existing drivers.

A beta test of the new software will be run during the second quarter of 1996. The Dtpl.exe utility, which assists developers in creating CIS that is compatible with Windows 95, is being updated to reflect the changes described in this paper. This utility will be posted on the Microsoft FTP and web servers during the beta test.

References and Resources

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