PC Card Primer

Introduction

In the early 90's, the rapid growth of mobile computing drove the development of smaller, lighter, and more portable tools for information processing. One of the most exciting of these innovations was PC Card technology. The power and versatility of PC Cards quickly made them standard equipment in mobile computers. The rapid development and worldwide adoption of PC Card technology has been due in large part to the standards efforts of the Personal Computer Memory Card International Association (PCMCIA).

The association's PC Card Standard is now bringing the benefits of these same PC Cards to a variety of industries and vertical applications, including smart cards, set-top boxes, automobiles, and others. The PC Card technology's compact size and ruggedness make it the ideal technology for a wide variety of applications.

Card Types (Type I, II, III)

The card types each have features that fit the needs of different applications. Type I PC Cards are typically used for memory devices such as RAM, Flash, OTP, and SRAM cards. Type II PC Cards are typically used for I/O devices such as data/fax modems, LANs, and mass storage devices. Type III PC Cards are used for devices whose components are thicker, such as rotating mass storage devices. Extended cards allow the addition of components that must remain outside the system for proper operation, such as antennas for wireless applications.

Releases (1.0, 2.0, 2.1, 5.0, 8.0)

PC Card Applications

• 10/100 Mbps Ethernet Adapters
• A/D Converters and other Data Acquisition Devices
• AM/FM Radio Tuner
• Biometrics cards (Fingerprint reader)
• Bluetooth cards
• CD-ROM Interface
• Cellular Phone Interface (WAN)
• Digital Camera
• Docking Station Interface
• Ethernet LAN Adapters
• GPS (Global Positioning System) Cards
• Hard Drives (Rotating)
• Infrared Wireless LAN Adapters
• ISDN Cards
• Joystick Interface Cards
• Memory Cards - Flash, SRAM, and many others
• Memory Cards Adapters - SD, , MMC, SmartMedia, CompactFlash, MemoryStick, etc.
• Modem/Ethernet Combination Cards
• Modem Cards
• Parallel Port Interface
• PDA PC Card
• Radio LAN Adapters
• SCSI Adapters
• Security Tokens
• Serial Port Interface
• SmartCard Readers
• Sound Cards, Input and Output
• Token Ring LAN Adapter Cards
• TV Tuner
• VGA
• Video Capture/Frame Grabber Cards
• Video Teleconferencing Cards

PC Card Compatibility

PCMCIA's goal is to make the technology as easy to use as possible, however, the Standard can only provide guidelines in some areas so there will be manufacturers who do not follow the Standard exactly or have interpreted it differently. Therefore, development planned for flexibility and adaptability will allow for the greatest compatibility. One way to be prepared for the variety of the real world is to perform exhaustive testing of designs with all the significant components from software functions and modules to entire platforms.

Over the years, three major factors that came together to greatly improve PC Card interoperability. The software specification for PC Cards were improved in a number of ways and improvements to the Card Information Structure and the guidelines for its usage improved the way that hosts recognize the features and requirments for a card when inserted. Also helping compatibility was the addition of the Guidelines document, a series of recommended guidelines for developers of specific types of PC Cards, such as modems, wireless devices, ATA cards and CardBus cards. In addition, increasing cooperation between card, host and software developers within the industry has resulted in vastly improved interoperability.

Intellectual Property

PC Card Standard Overview by Volume

Volume 1: Overview And Glossary

PCMCIA Standard Release 1.0/JEIDA 4.0 - June 1990

• 68-pin Memory-only Interface
• Type I and Type II Physical Form Factors
• Metaformat (Card Information Structure[CIS]) Defined

PCMCIA Standard Release 2.0/JEIDA 4.1 - September 1991

• I/O Interface
• Dual Voltage Memory Card Support
• Card Environmental Requirements
• Socket Services API Specification
• Enhanced Metaformat (Geometry and Interleaving Tuples added)
• XIP (eXecute In Place) Specification

PCMCIA Standard Release 2.01 - November 1992

• PC Card ATA Specification
• Type III Form Factor
• Auto-Indexing Mass Storage (AIMS) Specification
• Card Services API Specification
• Enhanced Socket Services support for Card Services
• Enhanced Metaformat to accommodate new PC Card functionality

PCMCIA Standard Release 2.1/JEIDA 4.2 - July 1993

• Card and Socket Services Greatly Enhanced
• Enhancements to Electrical and Physical Specifications
• Further enhanced Metaformat

PC Card Standard Release 5.0 - February 1995

• CardBus 32-bit Bus Mastering Interface
• Card Information Structure Required on all PC Cards
• Low Voltage-only Operation (3.3V)
• Support for Hardware Direct Memory Access (DMA)
• Industry standard power management interface (APM)
• Multiple Function Cards
• Guidelines Volume added

PC Card Standard 5.01 Update - March 1995

• General editorial changes

PC Card Standard 5.02 Update - May 1995

• Electrical Specification editorial changes

PC Card Standard 5.03 Update - November 1995

• Support for Custom Interfaces

PC Card Standard 5.04 Update - March 1996

• Added Zoomed Video (ZV Port) Custom Interface and Flash Translation Layer (FTL)

PC Card Standard Release 6.0 - March 1997

• Thermal Ratings System
• ISDN, Security, and Instrumentation Card Tuples
• Hot Dock/Undock Support
• Streamlined PC Card Configuration

PC Card Standard 6.1 Update - April 1998

• PCI Power Management
• Small PC Card Form Factor
• Win32 Socket Services Bindings

PC Card Standard 7.0 Release - February 1999

• PC Card Memory Paging
• DVB Custom Interface
• Windows NT 4.0 Kernel mode Socket Services Bindings

PC Card Standard 7.1 Update - March 2000

• OpenCable(TM) POD Custom Interface

PC Card Standard 7.2 Update - November 2000

• Removal of support for Direct Memory Access (DMA)
• Zoomed Video (ZV) Port Register Model
• Updated PC Card ATA Specification
• Limited Host Guideline

PC Card Standard 8.0 Release - April 2001

• CardBay USB Interface
• Vcore Supplemental Voltage

Volume 2: Card Electrical

PC Card/CardBus Throughput

16-bit I/O Transfers (255 ns Minimum cycle)
* Byte mode: 3.92 Mbytes/sec
* Word mode: 7.84 Mbytes/sec

16-bit Memory Transfers (100 ns Minimum cycle)
* Byte mode: 10 Mbytes/sec
* Word mode: 20 Mbytes/sec

CardBus (32 bit burst mode)
* Byte mode: 33 Mbytes/sec
* Word mode: 66 Mbytes/sec
* DWord mode: 132 Mbytes/sec

Please note that actual throughput may be substantially less than the theoretical maximums of the interface.

CardBus

Characteristics

The CardBus interface enables many new PC Card applications and provides a means for the enhancement of current PCMCIA product offerings. It introduces several important new capabilities and functions to PC Card applications, and is compatible with all new features and capabilities that were introduced with the new PC Card Standard. CardBus features and capabilities include 32-bits of address and data, 33 MHz Operation and Busmaster operation.

CardBus presents an opportunity to expand the set of applications now available to PC Card users. The new interface supports operational speeds up to 33 MHz.

The CardBus interface supports multiple bus functions which may be implemented in any combination. Use of a bus master function allows the system processor to be offloaded. This is a very important factor in multitasking environments, which can lead to improved system throughput capabilities.

The CardBus interface supports the existing PC Card Audio Digital Waveform mode and a new audio mode called Pulse Width Modulation (PWM). Both the Audio Digital Waveform and the PWM mode are optional in CardBus and must be enabled by system software before they may be used. The operating range of PWM audio is significantly improved over that provided by the original PCMCIA Standard Audio Digital Waveform signal.

While CardBus is defined with system platform independence in mind, it is intended for use on 32-bit systems. Systems employing a 16-bit bus will realize little, if any, benefit from a CardBus interface. Interchangeability between systems employing CardBus will be significantly increased due to several features of the new specification. Also, the CardBus specification includes a definition of the minimum requirements for cards, sockets and adapters.

Synergy

The CardBus interface signaling protocol is derived from the Peripheral Component Interconnect (PCI) Local Bus signaling protocol. There are some differences between PCI and CardBus; however, operations are identical for most functions implemented.

The CardBus software model is shared with that for 16-bit PC Cards. Since a 32-bit Card Services interface is also defined for 16-bit PC Cards, this allows the same Card Services client to be used to manage both CardBus and non-CardBus PC Cards.

Cards

Since CardBus cards and sockets use the Low Voltage Key defined for 3.3 Volt cards, CardBus cards must be designed for 3.3 volt, or lower, operation. The 3.3 volt, or lower, operation reduces system power requirements and extends battery life.

In addition, all CardBus cards must use a limited amount of power upon initial power-up or reset until after the card is configured. This specification permits the card CIS to be read, from which it may be determined whether the system is capable of providing sufficient power and other hardware resources for the card to function properly. The power-on current limit prevents instantaneous battery drain and enables the system to gracefully reject the card if it is not capable of providing the necessary power for operation.

Sockets

CardBus sockets must be able to accept and support all 16-bit PC Card within the constraints imposed by the host system (e.g., 5 volt only PC Card cannot be supported in any system which supplies only 3.3 volts. This is true for both CardBus and non-CardBus interfaces).

The CardBus interface supports insertion and removal of cards while a system is powered-ON (i.e., Dynamic Reconfiguration). The socket must be powered-OFF when a card is not present. To the user, this appears as though the socket is "hot" during insertion and removal events.

Adapters

As previously discussed, CardBus is required to also support PC Cards not utilizing CardBus. By interrogating the card upon detection of an insertion event, the PC determines whether the card requires CardBus support or not, and then applies the appropriate amount of power and resources. This interface is designed to prevent damage to the inserted card.

The Card Detect/Voltage Sense algorithm provides for two future lower voltage levels. All CardBus and low voltage non-CardBus cards are required to support this detection algorithm. It enables CardBus adapters to recognize any PC Card, in any socket. The adapter provides information to enable associated software to determine whether the inserted card can be supported, and if not, an opportunity to gracefully reject the card.

System Software

Socket Services is provided independent of whether or not an adapter supports CardBus. Different Socket Services implementations are, however, required for each unique adapter design. A single host system may contain adapters which only support CardBus as well as those which do not. It follows that the corresponding Socket Services handlers may also co-reside in a single host system. Minimum Socket Services functionality is required for all adapters.

Card Services is used to provide a consistent, abstract view of all PC Cards' specific capabilities and status. While little change to the Card Services is required to support CardBus, more significant changes are required internal to Card Services in order to provide complete compatibility for both CardBus and non-CardBus. As with Socket Services, a minimum Card Services functionality is required. Each function on a CardBus card must be described by a CIS.

Configuration

Upon detection of the insertion of a PC card, the PC will establish the PC Card's voltage and signaling protocol requirements. If the card's voltage and other requirements can be supported by the system, the PC will supply the correct signaling protocol and voltage. If the card's voltage requirements or any other requirement can't be met, the user should be notified "gracefully" that the card can not be operated in this system.

Once a card is recognized, cards may draw only a limited amount of current to guard against excessive battery drain. Configuration by generic enablers is also supported. The CardBus interface also provides support for multifunction CardBus cards. Each card may be divided into 1 or more functions, up to a maximum of 8 functions per card.

Conclusion

CardBus is the high-performance 32-bit/bus master interface from PCMCIA. It provides the opportunity for migration of most high performance functions available on desktop and larger systems to CardBus cards for use in the mobile environment. New functions developed for CardBus may also be used in 32-bit desktop systems, if they are equipped with CardBus sockets.

While CardBus is derived from PCI, it may be implemented on any 32-bit system that provides functionality similar to that provided by PCI. Although it is not the same as PCI in all respects, the signaling protocols are identical. CardBus is an extension of previous PC Card software capabilities. All CardBus sockets must be able to accept and operate PC Cards not utilizing CardBus within the capabilities of the system.

Introduction

A rapidly increasing number of the electronic components used in portable computing platforms today are capable of operating at 3.3 volts Vcc. Operating at 3.3 volts provides considerable power savings in these platforms, significantly extending battery life. It is anticipated that in the future, battery powered portable computing platforms will operate totally on 3.3 volts.

As the body responsible for the technical standardization of the widely accepted PC Card technology, PCMCIA set out to specify 3.3 volt operation for PC Cards. As with the advancement of any established standard, this effort had to consider two important issues.

First, there are thousands of PC Cards and PC Card computing platforms in the hands of users today. These products all operate at 5 volts and were not designed to accomodate 3.3 volt operation. Therefore, a new 3.3 volt option had to protect a new 3.3 volt PC Card from damage if the user inadvertently inserted it into an existing 5 volt platform. And, at the same time, a new 3.3 volt platform would not be damaged if an existing 5 volt PC Card were inserted.

The second consideration was that of product migration - the chicken and egg problem that is created by many technological advances. Since all of the PC Cards available today are 5 volt cards, a platform vendor would be hesitant to introduce a 3.3 volt platform as no cards would be available for its use. At the same time, all of the platforms on the market today are 5 volt platforms, so a card vendor would be hesitant to introduce a 3.3 volt card. PCMCIA therefore concluded that a viable 3.3 volt specification had to address both of these concerns.

The 3.3 Volt Option

The additions to the PC Card Standard to provide the 3.3 volt option effect three areas. First, in the PC Card Physical Standard, a new keying for the existing 68 pin socket and card connector is defined. The keying defined in previous releases of the standard remains and is now known as the "5 volt key". Therefore, all existing products are compliant with the new standard as they utilize the "5 volt key".

The new keying is referred to as the "low voltage key." A card with the new "low voltage key" will not physically insert into a socket with the "5 volt key." Therefore, a new 3.3 volt card is protected from damage that might occur if it were inserted into a 5 volt socket.

On the other hand, a socket with the new "low voltage key" will accept cards with either the "low voltage key" or the "5 volt key". This allows a platform manufacturer to build a product capable of supporting both new 3.3 volt cards and existing 5 volt cards.

In the PC Card Electrical Standard, two new signal lines are defined across the PC Card interface. These were previously unused lines in the interface that were left unconnected in previous releases of the PC Card standard. They are now defined as voltage sense lines, VS[2::1]. If both VS1 and VS2 are unconnected in a PC Card, the PC Card is identified as being capable of 5 volt operation. Therefore, all existing cards are compliant with the new standard.

If a PC Card is capable of operating at 3.3 volts, VS1 is grounded in the PC Card and VS2 is unconnected. Since both "low voltage key" and "5 volt key" PC Cards may be inserted a platform with a new "low voltage key," the platform can determine the voltage at which a PC Card may be operated before supplying power to the PC Card. The platform will only power the PC Card if it is capable of providing a voltage the PC Card can accept. If the platform is incapable of providing the power the PC Card requires, it may display an error message on the screen to notify the user of that fact.

Finally, in the PC Card Metaformat Standard, the definitions of the CISTPL_DEVICE, CISTPL_DEVICE_A, CISTPL_DEVICE_OC, and CISTPL_DEVICE_OA tuples were extended. Again, the tuples required for a 5 volt PC Card are exactly as they were in previous releases of the standard which means that existing PC Cards are compliant. The extensions allow a PC Card capable of operating at 3.3 volts to describe that fact and describe its operating characteristics at that voltage. A PC Card capable of operating at either 3.3 or 5 volts, can express that and describe its operating characteristics for each voltage.

Product Migration

The 3.3 volt option as defined in the 5.0 release of the PC Card Standard provides a graceful path for product migration. Existing products developed under the previous release of the standard are totally compliant.

A host platform vendor who wishes to begin the migration can implement a host platform that is capable of supplying either 5 volts or 3.3 volt to a PC Card. This platform will have the "low voltage key" socket so that both existing and low voltage PC Cards can be inserted. Before powering a PC Card, the voltage sense lines will be interrogated so that the PC Card is powered to the proper voltage. The advantage is that all existing PC Cards will operate, and as 3.3 volt PC Cards begin to appear the lower power consumption of the newer PC Cards can be utilized.

At the same time, card vendors may begin the migration by implementing PC Cards capable of operating at either 5 volts or 3.3 volts. These PC Cards will have the "5 volt key" so that they will insert into either existing or new platforms. If inserted into an existing 5 volt platform, they will be powered at 5 volts and operate. If inserted into a new platform implementing the 3.3 volt option, the platform will interrogate the voltage sense lines and power the PC Card at 3.3 volts.

This configuration of a platform capable of operating PC Cards at either voltage and a PC Card capable of operating at either voltage brings an interesting new tradeoff to the host. This type of PC Card may consume less power at 3.3 volts, but may have better performance characteristics at 5 volts. Since the PC Card supplies these characteristics in its Card Information Structure (CIS), the host may choose which voltage to operate the PC Card based on its desired result.

PCMCIA recognizes that rapid advances in the miniaturization of components are allowing developers to place more functionality on a single PC Card. Providing multiple functions on a single PC Card, such as modem and LAN, effectively doubles the amount of functionality that each PC Card slot provides. While so-called "Combo-Cards" have been available in the past, the Standard now provides a standard method to provide this multiple functionality, which will enhance both the performance and compatibility of these devices.

Why Were Changes to the Standard Needed?

The release prior to the 5.0 Release did not specify how to implement Multiple Function PC (MFPC) Cards. It did not prohibit them, but it left the implementation details to the card manufacturer. Without direct support for such PC Cards, using them in a host system required specialized device drivers to enable and connect to the features provided by the cards.

Requiring any use of MFPC Cards to need a specific client device driver severely limits the interoperability of such a card and increases the potential for compatibility problems. Before an MFPC Card can be used on a host platform, a specific client device driver has to be created for the combination of the card and the host environment. Instead of allowing the host platform manufacturer to develop a generic handler for all cards providing the card's functionality, another client device driver is required. If an end-user wished to use the MFPC card in addition to a single function card delivering some of the same capabilities, both drivers would have to be available in the host system, potentially wasting available system resources.

Design Issues and Goals

Handling a PC Card that delivers multiple I/O functionality to a host platform in a generic manner requires a number of questions to be answered:

1. How are multiple functions described in the PC Card's Card Information Structure?
2. How can single function host software utilize one function on a multiple function PC Card without affecting any other funtion?
3. How do multiple I/O functions share the single PC Card IREQ interrupt signal?
4. How are the individual I/O port ranges used by each function mapped into host system address space?
5. How are PC Card supply and control voltages managed independently for each function?

Answering the above questions generated the following design goals:

1. The function specific information to configuration information in the Card Information Structure.
2. Allow independent use of multiple functions on the card by multiple clients including the ability to individually enable, control, disable and report status for each function.
3. Since there is a single IREQ line, develop an interrupt sharing protocol that allows multiple functions on the PC Card to share interrupt notifications. Support existing software that may be unaware of interrupt sharing.
4. Avoid requiring a protocol for inter-client communication in order to share a PC Card outside of the current programming model used by Card Services.
5. Do not require any change to socket hardware as currently built.
6. Minimize impact to existing system software. If existing software may not be used with MFPC Card, do not cause existing software to malfunction if it encounters such a card.

Based on the above, the following changes were made to the PC Card Standard:

1. Separate configuration registers for each function.
2. Additional configuration registers to define the I/O address range used by each function.
3. Additional tuple (CISTPL_LONGLINK_MFC) added to the Metaformat.
4. Slight modifications to existing configuration registers to support sharing the IREQ signal between functions.
5. Modifications to Card Services to support individual control and event notification for each function on the multiple I/O function PC Card and support IREQ sharing.

To eliminate interaction between multiple functions on a PC Card, each function has its own set of configuration registers. Host software only interacts with the registers related to the function being managed and each function is completely independent.

Each function specific Configuration Option Register uses individual bits to signal function specific configuration information:

Bit 0    Function specific enable
Bit 1    Enable function specific Base and Limit Registers
Bit 2    Enable function specific IREQ routing
Bit 3-5  Reserved for vendor implementation

When IntrAck is set to one (1), the function requires a positive acknowledgment when the host system has completed processing the interrupt event and the system is ready to accept another interrupt notification. The system notifies the PC Card it is ready for another interrupt by resetting the Intr flag to zero (0). If the function (or any function on the PC Card) is signaling another interrupt event, the card must again notify the host system of an interrupt condition. Since the card must signal if any function on the card that has interrupts enabled requires service, the Intr bit is aliased to all functions having the IntrAck bit reset to zero (0).

Additional Configuration Registers

Additional configuration registers are defined just after the I/O Event Register - up to four Base Address Registers and a single Limit Register. These registers are written by the host software when the function is configured. The base of the range of I/O registers used by the function in host system address space is written to the Base Address registers before the function is enabled by writing the Configuration Index. This allows host software to place the function wherever desired in host system space. The Limit Register describes the size of the I/O range used by the function. Each bit in this register represents an address line, and all bits to the right of any bit set to one (1) must also be set to one (1). This requires I/O ranges to be sized as a power of two.

Configuration Information in the CIS

Once the premise of separate configuration registers for each function was accepted, it was a simple matter to provide function and configuration register descriptions for each function in the Card Information Structure (CIS). The PC Card Standard describes a Primary CIS for global items and a separate Secondary CIS for each function on the card.

The Primary CIS on an MFPC Card is formatted the same as for single function PC Cards. The Primary CIS contains a new tuple (CISTPL_LONGLINK_MFC) describing the location of a separate Secondary CIS for each function on the card. Each Secondary CIS contains a function ID tuple, optional function extension tuples, configuration table tuple and one or more configuration entry tuples.

The presence of the Base Address and Limit Registers are noted in the Configuration Tuple Configuration Registers Presence Mask. An implementation may choose to limit the number of Base Address Registers by resetting corresponding bits to zero. For most environments, at least two Base Address Registers are required to allow I/O ranges to be placed within a 64 KByte I/O address space.

The single Limit Register may be eliminated if all possible configurations for a function use the same number of I/O address lines.

Interrupt Sharing Protocol

Each function must support enabling and disabling interrupt notification through its Configuration Option Register using Bit 2. In addition, each function must use the Intr and IntrAck bits as described above.

When multiple functions on a PC Card use interrupt notifications on the card's single IREQ line, it is important that End Of Interrupt (EOI) processing be performed only once. The preferred method of insuring that EOI processing happens only once is to have Card Services receive all interrupt notifications and dispatch them for function specific processing to registered handlers. When all handlers have completed processing, the Card Services handler performs EOI processing, resets the Intr line on the card and returns from the interrupt notification.

Interrupt handlers for multiple function PC Cards are registered with Card Services using an extended RequestIRQ function. The arguments include a pointer to a callback handler for the client's interrupt handler. If the request is successful, Card Services sets the AssignedIRQ field in the RequestIRQ packet to the assigned IRQ level, which may already be in-use by other functions on the PC Card. Interrupts from the PC Card transfer control to the Card Services interrupt handler. The Card Services handler then transfers control to the entry point registered by the client using the RequestIRQ function via a CALL instruction. The client handler processes the notification and returns control to the Card Services handler by executing a RET instruction.

The client interrupt handler may modify any host system registers. The Card Services interrupt handler restores all registers to their entry value before returning from the interrupt notification.

Interrupt handling is more complicated if the enabling client is only requesting interrupt routing on behalf of another software entity on the host system that may not have been loaded. For example, a generic enabler might configure the data/FAX modem function on a PC Card to use a standard COM port definition expecting a communications program loaded sometime later to simply use the port without realizing the port resides on a PC Card.

In this case, the client registers without providing a pointer to a callback routine. Instead, Card Services assigns another available IRQ level to the client. When the PC Card signals a hardware interrupt, Card Services simulates a hardware interrupt using the additional IRQ level. Since traditional interrupt handlers perform their own EOI processing, the Card Services handler does not perform EOI processing. A new flag in the Attribute field indicates the interrupt routine is performing EOI processing. Only one client may set this flag to one (1).

The redirection routine within Card Services is responsible for determining if it is appropriate to transfer control to the handler of the simulated interrupt. It is possible that no handler has yet been registered for the simulated interrupt event. Typically, the redirection routine checks the Interrupt Mask Register (IMR) on the Programmable Interrupt Controller (PIC) to confirm the level of the simulated interrupt has been unmasked.

Introduction

Since its inception, PCMCIA has targeted portable platform products which rely on battery power for their power source. As a result, one important issue that platform vendors and users have had to continually struggle with has been useful battery life. In the past, users and system vendors have tried every conceivable method to stretch the maximum amount of time from the battery.

Now, with the new release, PCMCIA has added power management functionality to the PC Card specification. With this added functionality, PC Cards can be added to the list of power-managed system components, thus increasing the useful life of the battery.

A Description Of The Task

A power management system requires three elements in order to be an effective power manager - BIOS support at the motherboard level, a driver that controls power management policy, and power management-aware clients, which would include both application and device drivers. In most systems today, the first two elements are already present. However, one of the key elements, power management-aware clients, has been missing. The missing power management-aware clients, which include device drivers, are just as important as the other two elements in achieving true power savings.

In products designed to the old standard, a PC Card vendor had to provide three additional pieces to ensure good power managment: the card with power management capability, an enabler (preferably a Card and Socket Services client), and a power management-aware device driver. Without power management capability, when the card is inserted in the host platform, it becomes a constant drain on the life of the battery, with no ability to minimize this drain.

Providing a power management-aware driver has not been an easy task. The complexity can be daunting when all the required components are considered. In order for power management to be successful in the PC Card environment, a method to simplify this task and ensure reliability was needed.

Card Services And Power Management Functionality

With power management functionality added to PCMCIA's Card Services Specification, the PC Card vendor can provide a single Card Services client driver that can both reliably configure and manage the power of the PC Card. All the pieces required are now woven together in one convenient, well-defined interface to which the card vendor can write an appropriate client driver. This client driver is now much simpler since the tools that detect when the targeted card is inserted or removed, and when it is appropriate to perform requested power management actions, are provided.

Central to the power management theme are the suspend and resume functions. The resume operation is used when the host system is returning from a lower power state. A short time lapse is acceptable while this operation is taking place, although it is generally agreed that quicker is better. When a suspend notification is issued, the host power manager reduces system functionality (and battery drain) by placing unused system resources in a lower power, non-useable state.

Two types of resume are specified in the power management support addition to Card Services: normal resume and critical resume. Basically, normal resume is issued if the suspend operation was successful and critical resume is issued if a system was not successfully suspended.

Finally, notification of begin and end resume functionality has been added so the card client driver knows what part of the cycle is taking place.

There is one link necessary to make this successful. That link is between Card Services and the host's power manager. Generally, the host platform provides Card Services and the host platform provides a power manager. Since both pieces are under the auspices of one vendor, there is no reason why these two pieces should not work together. When all the tools are in place to enhance the battery life that is so vital in the portable arena, everyone wins.

Introduction

The Zoomed Video port (ZV Port) offers an attractive alternative to the traditional video input methods such as VAFC (VESA Advanced Feature Connector). ZV Port offers a low-cost, simple multimedia solution for the notebook designer, as well as the user. The notebook computer now has a development model that closely reflects the plug-in board model of desktop machines. This new technology allows portables to evolve at a pace that is on par with desktop machines by providing multimedia solutions that fit into a PC Card form factor.

The Zoomed Video specification provides for an inexpensive, full frame-rate video display channel for applications like MPEG decoders for movies and games, TV tuners, live video input and video capture. With the PC Card form factor, notebooks can equal today's desktop audio and video performance, without sacrificing flexibility.

ZV Port allows video data on a PC Card to be transferred directly into the VGA frame buffer. The ZV Port is a direct connection between a PC Card host adapter and a VGA controller. It allows the host adapter (or more precisely a PC Card plugged into the host adapter) to write video data directly into the video frame buffer. This video data is transferred real-time without any data buffering requirements being placed on the PC Card. This eliminates the need for the PC Card to provide bus mastering or bus arbitration logic because the video data is transferred over the dedicated ZV bus and not the system bus such as the PCI bus.

Why Another Bus?

A large percentage of multimedia applications involve a single video stream being decompressed by either a hardware or software codec (i.e., Video Playback). The PCI bus is adequate for these types of video applications.

Demanding multimedia applications, such as multiple video streams or games, may require a dedicated video bus. Running these applications over a single PCI bus may affect system performance due to interference between multiple masters which share the bus. Also, Windows 95 pre-emptive multitasking may cause dropped frames. These issues can be resolved by transferring multimedia data over a secondary PCI bus, but this increases system cost. One possible solution is to have a low cost ancillary bus in the system to offload the PCI bus. The purpose of the ZV-Port is to provide this alternative, low cost solution, while maintaining flexibility and ease of use.

Applications

The following examples illustrate how the ZV Port supplements the PCI bus utilization in multimedia applications. Live Video from a real-time source:

In this type of application, 60 fields of interlaced video have to be transported in an uninterrupted manner from a source (i.e., video encoder) to a destination (i.e., the display screen) in a system.

In order for this to occur, a contingency issue must first be resolved. A system with a single PCI bus can handle live video, but in practice, it is difficult to ensure that enough bandwidth is available. The only way to guarantee that there will be no "video tearing" at the destination or display point is to have enough memory at the source point to buffer at least one full frame of video data (a little over a 1/2 megabyte of memory).

One way to guarantee uninterrupted 30 frames per second video at the destination point is with a dedicated bus like ZV Port. With a dedicated bus, the video is directly connected to the display controller, which enables the video stream to flow uninterrupted from the source to the destination, and eliminates the need to buffer the video stream at the source. Video capture

Another application for Zoomed Video is capturing video to disk. To capture and view the video, the video source controller must bus master the same video asynchronously to two different destinations- the display screen and the disk or storage device. This is expensive and requires a PCI bus mastering controller at the source. With ZV Port, a PCI bus master is not required. The video data is supplied via the ZV Port to the display controller where it is displayed. The capture-to-disk operation is then controlled by the CPU, which pulls the data out of the display frame buffer and sends it to the storage device. This is a true "what you see is what you capture" operation. MPEG-based games

MPEG-based games place more stress on a system than MPEG playback. A PCI bus can handle MPEG playback without any strain, but MPEG-based games require the system to keep a MPEG decoded video stream flowing to the display, render 3-D graphics images, and mix them with the video at some point between the MPEG decoder and the display screen. MPEG-based games will evince the demand for a supplementary video bus to be in the system. A MPEG decoder streams the video straight into the frame buffer via the ZV Port by giving the CPU almost 100% utilization of the PCI bus for rendering the graphics into the same frame buffer. The graphics engine has the responsibility to mix the two streams and send them to the display.

What Is The ZV Port?

The ZV Port is a point to point uni-directional video bus between a PC Card host adapter and a VGA controller. The ZV port complies with CCIR601 timing to allow NTSC decoders to deliver real-time digital video straight into the VGA frame buffer from a PC Card via the PC Card host adapter and the ZV Port.

How It Works

The PC Card host adapter has a special multimedia mode configuration. In this mode the PC Card connector pin assignments change. The ZV Port proposal prescribes how a ZV Port PC CardZV Card transitions from its initial PC Card memory mode into ZV Port mode. The PC Card Standard specifies both the hardware interface and the software interface to a ZV Port PC CardZV Card, to ensure compatibility with other PC Cards. The multimedia-mode PC Card is required to meet all existing power-on and hot plug-in requirements. But once the card has been plugged in and the host adapter has been switched to this special multimedia mode, the pin assignments change to reflect the block diagram shown on the previous page. If a non-ZV PC Card is plugged into the slot, the host adapter is not switched into the special multimedia mode, and the PC Card will behave as expected.

In the special multimedia mode, the control and data signals on the PC Card bus stillwill follow the same data path to the ZV Port PC CardZV Card as they dowould for any other PC Card. The only difference is that the addressing range will be restricted to 16 bytes of common and attribute memory. When the multimedia mode is selected in the PC Card Host Adapter, address line A [25::4] to the PC Card are either put in three-state by the Host Adapter or become inputs to the Host Adapter. In ZV mode, the address lines A[25::4], BVD2/SPKR#, INPACK# and I0IS16# signals are replaced by ZV Port signals which carry video/audio data from the PC Card to the ZV Port. The multimedia PC Card does not support memory mapped addressing. The unused address pins and three control pins are used to define the 19-pin ZV data bus and controls, and a 4 channel digital audio.

Software Considerations

The PCMCIA components are: 1) Socket Services, which is used to manage the mode-switching in the PC Card host adapter; and 2) Card Services, which is used to detect and enable ZV Port PC Cards using the ZV Port interface.

Audio is managed via the existing MCI API. A new piece of software is required to control ZV Port; this is exemplified by the Video Port Manager (VPM) API. The following diagram also shows how software is layered on top of the PC Card host adapter, audio codec, and VGA controller.

Conclusion

The Zoomed Video Port offers an attractive alternative to traditional video input methods and provides an inexpensive, full frame-rate video display channel for applications like MPEG decoders for movies and games, TV tuners, live video input and video capture. ZV Port also offers a low-cost, simple multimedia solution for the notebook designer. With ZV Port, the mobile user has a broad range of options to choose from in adding multimedia to their notebook configuration, and notebook designers can reduce the cost of their notebooks by offering multimedia options as an aftermarket upgrade.

Volume 3: Card Physical

+==========================================+
| PC Card Physical Characteristics         |
+====================+=====================+
| Physical Interface |  68 Pins            |
| Back End I/O Conn. |  Proprietary*       |
| Length             |  85.6 mm            |
| Width              |  54.0 mm            |
| Thickness          |  Type I = 3.3 mm    |
|                    |  Type II = 5.0 mm   |
|                    |  Type III = 10.5 mm |
| Operating Temp.    |  0 to 55 C          |
| Storage Temp.      |  -20 to 65 C        |
| Minimum Insertions |  Office Env. 10,000 |
|                    |  Harsh Env.  5,000  |
+====================+=====================+

* Two standardized connectors are available as part of the optional PCMCIA Specific Extensions Specifications.

Volume 4: Metaformat Specification

The Basic Compatibility Layer - specifies a minimal level of card-data organization. Tuples at this level provide fundamental information about the PC Cards including supported configurations, manufacturer, and individual device characteristics such as size, speed, and programming information. An example of a tuple from the Basic Compatibility Layer is the Function ID Tuple, shown here.
+====================================================+
| CISTPL_FUNCID: Function Identification Tuple       |
+----+------------------+----+----+------------------+
|Code| Name             |    |Code| Name             |
+====+==================+====+====+==================+
| 0  | Multi-Function   |    | 7  | AIMS             |
+----+------------------+    +----+------------------+
| 1  | Memory           |    | 8  | SCSI             |
+----+------------------+    +----+------------------+
| 2  | Serial Port      |    | 9  | Security         |
+----+------------------+    +----+------------------+
| 3  | Parallel Port    |    |A-FD| Reserved         |
+----+------------------+    +----+------------------+
| 4  | Fixed Disk       |    | FE | Vendor-Specific  |
+----+------------------+    +----+------------------+
| 5  | Video Adapter    |    | FF | Do Not Use       |
+----+------------------+    +----+------------------+
| 6  | Network Adapter  |    |    |                  |
+====+==================+====+====+==================+

The Data Recording Layer - includes tuples which describe partitioning information and provide card initialization information.

The Data Organization Layer - currently includes a single tuple, CISTPL_ORG, which specifies the partition organization (for example, the file system) in use in a partition described by Data Recording Format Layer tuple(s).

The System-Specific Layer - includes the special purpose tuple, CISTPL_SPCL, and the range of vendor-unique tuple codes. The special purpose tuple provides a mechanism for documenting the format and interpretation of special tuple usage within the PC Card Standard. the format and interpretation of special tuple usage within the PC Card Standard. The format and interpretation of any tuple inthe vendor-unique range is not documented within the Standard.

Volume 5: Card Services

Volume 6: Socket Services

Volume 7: PC Card ATA

Volume 8: PC Card Host System Specification

PC Card Power Availability (per slot)

Voltage	Current Type	3.3 V Value	5.0 V Value
Vcc	Peak	1000 mA	660 mA
Vcc	Average	750 mA	500 mA
Vcc	Static	500 mA	330 mA
Voltage	Current Type	For all voltages*
Vpp	Peak	50 mA	50 mA
Vpp	Average	50 mA	50 mA
Vpp	Static	50 mA	50 mA

* Typical values for Vpp are Vcc or 12.0 V

Volume 9: Guidelines

• Enhance the interoperability of PC Card components, including systems and cards hardware and software, and applications.
• Facilitate the development of PC Card hardware and software by increasing the understanding of the standard by developers.

• Enabler Capabilities and Bahavior
• Card-Application Behavior
• Fax/Modem Card Information Structure Design
• Wireless Card Information Structure Design
• Sample PC Card ATA Tuple Options
• CardBus/PCI Common Silicon Requirements
• CardBus Operational Scenarios
• Guidelines for CIS Tuples for 3.3 or 3.3/5 volt Operation
• 15-pin Shielded Modem I/O connector
• 7-pin Modem I/O connector
• Recommended Extensions section provides physical specifications for Type III, and Type I and II Extended form factors.
  

Volume 10: Media Storage Formats

• MS-DOS BPB/FAT Format
• Linear File Store
• Flash Translation Layer

Volume 11: eXecute In Place (XIP)