This section summarizes PC Card requirements and standards for socket controllers.
2. Support the Industry-standard ExCA base-register set
| Required |
The built-in PC Card 16 software in Windows includes drivers for the Industry-standard ExCA – compatible socket controllers. To be compatible with these drivers, socket controller implementations must support the Industry-standard ExCA base-register set. Notice that some controllers do not fully implement the base-register set and are incompatible. Also, some controllers implement extended registers or enhancements. The built-in Windows drivers do not exploit these features, even though the controller might be compatible.
3. Maintain mapping of IRQ Routing Register bits to system interrupt vectors
| Required |
The system design must maintain the mapping of the PC Card controller's IRQ Routing Register bits to system interrupt vectors. This means that when an interrupt is programmed in the controller to occur on the IRQx pin, the system's IRQ routing causes the interrupt controller to generate the interrupt vector for IRQx, and no other IRQ.
4. Support the industry-standard definition for CardBus bridges
| Required |
If the system supports CardBus, it must support the definition in "PCI to PCMCIA CardBus Bridge Register Description" ("Yenta" specification) for CardBus controllers (PCI-to-CardBus bridges). This definition includes a common PCI configuration space header assigned the Header Type field value of 82H. Although this is not yet incorporated into the PCI standard, Windows supports it. Any controller features that are not part of the "Yenta" specification will not be used in standard drivers. Any hardware-initialization or setup required to make the controller comply with "Yenta" or the other requirements listed here are the responsibility of the BIOS.
Because CardBus host controllers are PCI bus bridges, they will be supported (enumerated and configured) by the PCI software in Windows in the same manner as other PCI bus bridges. For information, see the "PCI" chapter in Part 3 of this guide.
5. Support both ISA and PCI interrupts on CardBus controllers
| Required |
The PC Card software will dynamically configure the bridge to utilize ISA interrupts for PC Card 16 cards, and use PCI interrupts for CardBus cards. Notice the requirement to "maintain mapping of IRQ routing" earlier in this section also applies to CardBus controllers. Also notice that systems implementing CardBus controllers must fully support PCI v. 2.1 and the additional PCI requirements for IRQ routing described in the "PCI" chapter in Part 3 of this guide.
6. BIOS initializes CardBus controller in 82365-compatible mode and reports it as PNP0E03 for backward compatibility
| Recommended |
CardBus host controllers are enumerated and configured in Windows 95, just as other PCI bus bridges. The PCI bus bridge support in Windows 95 is based on new requirements for PCI interrupt routing and bridge-window configuration. Because of this, full compliance with the latest PCI requirements is required for CardBus support.
For backward compatibility with Windows 95, there are steps the BIOS can take. Specifically, the BIOS must initialize the CardBus controller in Intel 82365-compatible mode and report it as device "PNP0E03, Intel 82365-compatible CardBus controller." Specifically, the requirements are as follows for BIOS POST time (CardBus controller ConfigSpace initialization):
This puts the CardBus controller into Legacy mode where Socketsv.vxd (the Windows 95 Socket Services driver) can access it as an Intel PCIC-compatible controller at an I/O address (for example, 0x3e0).
Notice that the BIOS must be at least PCI 2.1 compliant, meaning that it must at least support BIOS function (AX=0xb10e) GetIRQRouting and return the necessary PCI IRQ routing information, including the routing information for the CardBus controller. In general, if the CardBus controller is on the system board, there must be a slot routing entry for it in the table. If the CardBus controller is a PCI add-on card, there must be routing information entries for each PCI slot in the system.
During Plug and Play BIOS enumeration, the BIOS should report the CardBus controller as *pnp0e03 with a compatible ID of *pnp0e00 and the I/O resource of two ports (for example, 0x3e0 – 0x3e1). Windows 95 does not know about *pnp0e03, but it does know about *pnp0e00, so it will load Socketsv.vxd (for generic Intel PCIC-compatible controllers) and everything will work with the above BIOS initialization. The Windows 95 PCI enumerator (Pci.vxd) does not know about the CardBus controller's PCI header (Type 2), so it will not report the CardBus controller device at all.
In Windows 95, when the BIOS enumerator sees *pnp0e03, it will hide the device and call the BIOS to disable it. When the BIOS receives the disable call for *pnp0e03, it should do the following:
7. Writable PCI Configuration Space bits not shared by CardBus controllers
| Required |
CardBus controllers are multifunction PCI devices, and Windows treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits (such as the Command register).
Notice that the PC Card 16-bit Interface Legacy Mode Base Address Register (offset 44h in the Type 2 PCI header) is the only exception to this requirement. This register must be shared between the two functions, as they must share the same registers for compatibility with the ExCA programming model.
8. Each R2 memory window in CardBus controller has it own page register
| Required |
For complete flexibility and support for typical configurations, CardBus controllers must support the independent location of R2 memory windows anywhere in the full system address space as recommended in the Industry-standard "Yenta" specification. Controllers that share a single page register among all R2 memory windows place the constraint on the system that all R2 memory windows must be located within the same 16-MB block. This is often not possible with typical DRAM (16 MB) and bridge (positive decode) configurations, and consequently will result in the disabling of cards in these cases.